sc34wg4 / opcRevision

Revision of ISO/IEC 29500-2 (Open Packaging Conventions)
1 stars 0 forks source link

Tables: Nested #57

Closed RexJaeschke closed 4 years ago

RexJaeschke commented 4 years ago

From WG4 N0441, “Plan to Make IS 29500 Parts Comply with the ISO Style Guidelines.”

During the 2019-09-03 teleconference [with ISO CS staff], it was pointed out that tables cannot be nested. Apparently, this approach is used in 29500-2. It certainly is used extensively in Part 1, especially in spreadsheet formulas (see §18.17.7.2, “ACCRINT”). Presumably these nested tables will need to be reformatted as lists.

To be investigated further. Do we have any in 29500-2?

murata2makoto commented 4 years ago

Yes, there is one such in the DIS. See Table B-5.

RexJaeschke commented 4 years ago

Proposal

As the values in Columns 2, 3, and 4 are the same regardless of the 4 possible bit-value combinations, how about we replace the nested table with the following text?

Any combination of bit values.

If that is not acceptable, we can use something like this:

Bits 2 and 1, in that order

  • 00 --- Normal (-en) compression option was used.
  • 01 --- Maximum (-exx/-ex) compression option was used.
  • 10 --- Fast (-ef) compression option was used.
  • 11 --- Super Fast (-es) compression option was used.
murata2makoto commented 4 years ago

FYI: There are 87 nested tables in 29500-1.

franciscave commented 4 years ago

The root cause of this issue in Part 2 is that the tables in Annex B repeat (unnecessarily, in my opinion, and probably unwisely) text descriptions directly from the ZIP Appnote. A slightly more drastic approach would be to get rid of the descriptions altogether, one of the consequences of which would be to lose the table embedded with Table B-5.

I know why the descriptions have been repeated: so that implementers don't have to cross-refer to the ZIP Appnote the whole time. But this is a standard, not a guide, so I think it would be appropriate to remove the duplication, especially as this is not a particularly lengthy specification.

I think that the bit descriptions (other than 'Currently unused' and 'Unused') could be replaced with 'Used' in Table B-5, and in Tables B-4, B-6 and B-7 the second column of the table could be removed in its entirety. Tables B-4, B-6 and B-7 already have the wording "... and described in the ZIP Appnote" above each table, so nothing further is needed. Table B-5 would need this or similar wording added.

The same cannot be done to Table B-1, B-2 and B-3, because the descriptions are needed for cross-referring to the ZIP Appnote, so these can be left as they are.

murata2makoto commented 4 years ago

@franciscave

I strongly believe that standards should not copy and modify normative descriptions from other standards.

Nevertheless, I have a mixed feeling here. Removing the second column from B-4,5,6,7 would make these tables quite cryptic. And ZIP Appnote is also cryptic and very difficult to find information.

franciscave commented 4 years ago

I agree that the ZIP Appnote is difficult to navigate, due to poor organization and misprints (e.g. 'VI General Format of a .ZIP file' should be 'IV General Format of a .ZIP file'). If we are to keep the descriptions, I think that Rex's second option is probably best. Rex's first option is too vague, I feel, although this could be extended to say something like 'Any combination of bit values, with the meanings ascribed to them by the ZIP Appnote when applying the DEFLATE compression method (method 8)'.

RexJaeschke commented 4 years ago

Francis/Alfred sent the following in email:

Here is a screen-shot of a possible revision of Table B-5 to remove the embedded table for bits 1 and 2, based upon Alfred’s suggestion:

ZIP-bit-map-table

On reflection I think that Alfred had a point about reversing the order of ‘1’ and ‘2’ in the first column. It makes it clearer that the left-most bit is bit 2 and the right-most bit is bit 1. Otherwise this has to be expressed in words in the second column, and that gets messy.

Alfred responded: I like it 😊

Although, would it make sense to have the same notation in the Bit column as in the Feature column, so either “2 0” and “0 0” or “2,1” and “0,0”?

Francis replied: Alfred, I'm not sure it would be better to have "2 1" in the first column. The meaning of "2,1" is more clearly "bits 2 and 1" than "2 1", which could more easily be misinterpreted to mean "bit 21".