AU

All parts

 

Ge Ed

The current name “Office Open XML” is confusing, with ISO Open Document Format (ODF), ISO Office Document Architecture (ODA) and the many various products, notable “Open Office”. Public usage has evolved into “OOXML” and “Open XML” as shorthands.

Furthermore, the name may appear to indicate a (non-standard) dialect of XML rather than a use of XML, which would be regrettable.

However, because “Office Open XML” is the title of Ecma 376 and in products, it is not suitable to change the name of the technology. A change in the name of the ISO Standard will suffice.

Change the name of the standard to “Information technology – Product-derived document format Office Open XML”

It is an Australian requirement that where there are multiple standards in the same space, they should clearly indicate their different application area. Some reviewers report the name causes confusion.

Some reviewers report that it is important not to differentiate the goals, development method and scope of DIS 29500 Office Open XML with that of IS 26300 ODF in particular.

AU

Part 1. 2

Para 2

Ge ed

Conformance and requirements as drafted are unacceptable. This can be corrected.

The important word “shall” is defined in Part 1 in a way that accords with ISO Directives Part 1.  However, the word “shall” is not used in this specification according to this definition, especially in Part 4. In multiple cases, “shall” is used for optional or even deprecated functionality. For example, in Part 4, s2.15.3 Compatability Settings and its subclauses.

Furthermore, Part 1 s2.4 and s2.5 specify that conformance is purely syntactic, which contradicts the definition of “shall” in part 1.2 which speaks of ‘behave’.

 

1)      Check and correct all uses of “shall” in the standard, especially Part 4, so that all “shall”, “should” etc are used in accordance to ISO Directives Part 2,

2)      Correct all uses of “shall” in Part 4 s2.15.3 and sub-clauses.

3)      Correct the sentence and conformance semantic to “Use of the word ‘shall’ indicates a requirement when used of syntax, and the typical behaviour otherwise.”

 

 

It is an Australian requirement that standards have clear conformance requirements. Some reviewers found the conformance issues unclear, for example with regard to Part 1 s2.15.3 and subclauses.

To encourage maintenance, we strongly urge option 1) is adopted. However, we are aware that this requires review of over six thousand uses of “shall”, consequently we suggest that adopting options 2) and 3) should be adopted even if option 1) is not adopted.

AU

Part 4, 2.15.3

Bullet list 2 starting “Compatability settings”

 

The usage of “ignorable” in Part 4, s2.15.3 is problematic, since it suggests some unexplained hierarchy: presumably it means that these elements are ignored by Office 2007 or that some typical Word Processor would not be expected to implement them

Change to “intended for use by specialist applications not typical applications.”

It is an Australian requirement that standards have clear conformance requirements.

AU

All Parts

 

Ge ed

The typesetting and layout of DIS 29500 are wasteful. This can be corrected.

This issue is important for a document of its size.

Typeset using 10 point body text. Follow ISO style guidelines.

It is an Australian requirement that standards should be physically printable. Some reviewers found the current size of Part 4 inconvenient and wasteful.

DIS 29500 is printed using 11pt. Experiments show that adopting 10pt saves around 800 pages from Part 4 alone.

To encourage maintenance, adopting ISO standard formats now would be helpful.

AU

All Parts

 

ge ed

The size or organization of DIS 29500 are unacceptable, This can be corrected.

DIS 29500 is too large, especially part 4, and it contains too much tutorial material. While this material is useful for users, it is burdensome for adequate review, printing and maintenance.

 VML is deprecated in the DIS and should be removed to its own part or annex.

The large size of Part 4 will be difficult for paper versions of the standard, but also makes the electronic version difficult (the PDF links from the TOC do not have sufficient grain to locate clauses.)

The FDIS should be split into 9 parts, each being capable of being considered complete standards. This largely mirrors the current chapter arrangement of Part 1 and Part 4, and would not seem be difficult editorially. The TOC of each should contain entries for each clause and sub-clause at any level.

1)      Open Packaging Conventions.

a.      DIS Part 1 clauses 1-7, 9

b.      DIS Part 1 clause 8 moved to s2 Scope

c.      Merge Part 2 OPC

2)      WordProcessingML

a.      DIS Part 1 clauses 1-7, 11

b.      DIS Part 1 clause 8 moved to s2 Scope

c.      Merge DIS Part 4 s1.1 and s4

3)      SpreadsheetML

a.      DIS Part 1 clauses 1-7, 12

b.      DIS Part 1 clause 8 moved to s2 Scope

c.      Merge DIS Part 4 s1.2 and s4

4)      PresentationML,

a.      DIS Part 1 clauses 1-7, 13

b.      DIS Part 1 clause 8 moved to s2 Scope

c.      Merge DIS Part 4 s1.3 and s5

5)      DrawingML,

a.      DIS Part 1 clauses 1-7, 14

b.      DIS Part 1 clause 8 moved to s2 Scope

c.      Merge DIS Part 4 s1.4 and s 6

6)      VML

a.      DIS Part 1 clauses 1-7, 15.2.7

b.      DIS Part 1 clause 8 moved to s2 Scope

c.      Merge DIS Part 4 s7

7)      Shared

a.      DIS Part 1 clauses 1-7, 15 (except 15.2.7)

b.      DIS Part 1 clause 8 moved to s2 Scope

c.       Merge DIS s1.5 and s8

8)      Extensibililty

a.      DIS Part 1 clauses 1-7, 10

b.      DIS Part 1 clause 8 moved to s2 Scope

c.      Merge DIS Part 5

9)      Schemas

a.      XML Schemas

b.      RELAX NG Schemas

c.      NVDL Schemas

Note that Part 3 is removed entirely, as it is informative. The normative parts of Part 1 are put with their appropriate specifications. The general introductory pages are repeated; this follows the pattern of IS 19757 in which all parts have the same introduction or scope material.

Part 4 Annex C should be split up.

Each part should indicate dependencies on other parts.

The Schemas should be available in their own part, as well as being available in file form. Publication-dependent formatting, such as line numbering is not appropriate. However, a clear index to the page number of each global declaration (complex type, element, etc) is important.

It is an Australian requirement that standards should be focussed and wieldy, both for online and paper reading. It is most likely that Australian implementers will be interested each on one or two particular parts only, and they will be better served by the proposed change..

It is an Australian requirement that standards should be physically printable.

Some reviewers found the size and organization of the draft difficult. It would be burdensome for maintenance for the current organization to continue. 

To encourage maintenance, a split standard would make it easier for working groups and task forces of experts in each field.

AU

Part 4

 

Ed

The repetition of complex type declarations in Part 4 increases the size of the specification unnecessarily.

Furthermore, though well-intentioned, its usefulness for reducing the work in reading the specification is dubious because many of the complex type declarations themselves reference other complex type declarations which are not present.

Remove all complex type declarations and replace them with a single sentence that references the appropriate section, either in the proposed Part 9 (i.e. the printed schemas) or in another section in a similar fashion to the the way simple types are currently handled.

It is an Australian requirement that standards should be focussed and wieldy, both for online and paper reading.

It is an Australian requirement that standards should be physically printable.

AU

All Parts

 

Ge ed

The treatment and completeness of references in the draft is unacceptable, This can be corrected.

Furthermore, it appears that several times there are numbers or codes used without explanation of their provenance.

Check all parts for references.

It is an Australian requirement that references and their status must be clearly specified. Some reviewers reported problems that could have been resolved by checking the appropriate reference, however the reference was missing.

AU

Part 4, s2.8 Fonts

 

Ge ed

Through this clause and its sub-clauses, the relationship with  ISO/IEC 9541-4: Information technology - Font information interchange - Part 4: Open Font Format (dual numbered as IS 14496-22) is not adequately clear. Presumably this is because IS 14496-22 was not published until after Ecma 376 was complete.

In particular this concerns IS 9541-1 s4.1.7 OS/2 – Global Font Information Table.

 

 

1.      DIS Part 4 S2.8 Fonts should contain a normative reference to IS 9541-4: or 14496-22

2.      S2.8.2.14 should clarify that Panose is used to conform with IS 9541-4:  or 14496-22.

3.      S2.8.2.16 should clarify that the values for the attributes of the <sig> element are standard values from IS 9541-4:  or 14496-22

It is an Australian requirement that references and their status must be clearly specified.

Some reviewers missed that the hexadecimal values in 2.8.2.16 were standard values, and had unnecessary concerns about the use of hexadecimal numbers, in this case.

AU

Part 4, s2.8.2.2 charset

 

te

The relationship between Part 4 s2.8.2.2 and other standards should be clarified.

Furthermore, IS 29300 matches fonts based on their IANA name, as may be more suited for non-Open Font fonts, such as fonts on Linux.

The mapping from values in IS 9541-4 or other standards should be clarified.

If there is no specific mapping, then the definition of s2.8.2.2 should be broadened to also allow characters identified by any string: such as an IANA font name.

It is an Australian requirement that references and their status must be clearly specified.

It is an Australian requirement that creators of documents can use standard data notations for fields where they exist and are relevant, in addition to any local, legacy or optimized notations.

Some reviewers noted that the values did not conform to commonly known standard values.

Some reviewers made general comments on the desirability of removing any platform dependencies. Even though Open Font is a standard and Open Type is available on all major platforms, there are some systems, such as Linux systems, where many fonts may use pre-Unicode conventions such as the name of the charset.

Note that even though this is a technical change, an application is not required to use (or even round-trip) this information, so it will not impose a burden on existing implementations at the data structure level or feature-support level..

AU

Part 4 s2.18.52 ST_LangCode

 

te

This data type does not accord with the ISO standard for languages, or with common practise for interchange formats.

 

1.      The mapping between the codes and the ISO language and country codes should be specified.

2.      The definition of s2.18.52 should be broadened to also allow standard country/locale pairs as well as the digits. Because these are lexically distinct, this should pose no trouble to parsers or datatyping.

3.      A normative reference to the appropriate ISO or IANA standards should be made.

It is an Australian requirement that creators of documents can use standard data notations for fields where they exist and are relevant, in addition to any local, legacy or optimized notations.

Note that even though this is a technical change, an application is not required to use (or even round-trip) this information, so it will not impose a burden on existing implementations at the data structure level or feature-support level..

It is an Australian requirement that references and their status must be clearly specified.

AU

Part 4 s3.17.6.7

 

te

This data type does not accord with the ISO standard for languages, or with common practise for interchange formats.

 

The definition of s3.17.6.7 should be broadened to also allow standard ISO 8601 dates, in particular, the XSD Date simple type, as well as the digits. Because these are lexically distinct, this should pose no trouble to parsers or datatyping.

 

It is an Australian requirement that creators of documents can use standard data notations for fields where they exist and are relevant, in addition to any local, legacy or optimized notations.

Note that even though this is a technical change, an application is not required to use (or even round-trip) this information, so it will not impose a burden on existing implementations at the data structure level or feature-support level.

It is an Australian requirement that references and their status must be clearly specified.

AU

Part 4, S5 (throughout)

 

te

The use of a fixed coordinate system that allows exact integer division of inches and centimetres is long established practise in typesetting systems. For example, gruff and PostScript. The English Metric Units of DrawingML is an example of this.

However, it is inappropriate that common dimensions cannot be used, and adds an unnecessary burden on the user (i.e. the developer).

Throughout s5, wherever English Metric Units are currently allowed, the type should be broadened to also allow standard measurements such as inches and centimetres. Because these are lexically distinct, having unit suffixes, this should pose no trouble to parsers.

The datatype will have to be adjusted accordingly, presumably to a regular expression pattern. As well all types that use EMU must be adjusted.

 

It is an Australian requirement that creators of documents can use standard data notations for fields where they exist and are relevant, in addition to any local, legacy or optimized notations.

Note that even though this is a technical change, an application is not required to use (or even round-trip) this information, so it will not impose a burden on existing implementations at the data structure level or feature-support level.

It is an Australian requirement that references and their status must be clearly specified.

AU

S3.17.2

 

te

The syntax of formulas is inadequately described.

Specify the syntax using ISO BNF or similar notation that allows a parser or validator to be constructed.

It is an Australian requirement that standards have clear conformance requirements.

AU

Part 4 s7.6

 

te

There is no reason to arbitrarily restrict the sizes of bibliographic fields.

Furthermore, the term “character” is difficult: are Unicode characters meant, or database “characters” which often relate to bytes?

The ST_String255 datatype should be removed, and replaced with XSD:String

All places which use ST_String255 should instead have an informative note: “For interoperability, use of strings greater than 255 Unicode characters in length is deprecated.” (or 255/3 = 84 characters if the constraint is bytes and we need to cope with Chinese/Japanese/Korean UTF-8)

It is an Australian requirement that legacy and interoperability limitations should be noted in standards.

 

AU

Part  4 s3.2.28 workbookPr

 

ed

The potential use of different date bases, which has a more generalized mechanism in by ODF, combined with the well-known leap-year problem with the 1900 base, means that dates before 1904 are not reliably interchangeable.

Add a warning “Use of dates before 1 Jan 1904 is deprecated.”

Also to Part 4 s3.1.7

It is an Australian requirement that legacy and interoperability limitations should be noted in standards.

Some reviewers noted the leap-year issue. Some reviewers noted the limits to dates. Some reviewers noted the difference in mechanism with ODF.

AU

Part 4 s3.18.96 ST_Xstring (Escaped String)

 

 

 

te

This datatype allows characters that are not allowed in XML markup to be represented. These primarily include are control characters.

While this might be a reasonable technique for encoding binary data, as an alternative to XML Schema’s Bin16 and Bin64 encodings, an examination of the elements which are defined using this datatype shows many if not all are simple strings, such as author name.

As a consequence, this datatype is highly undesirable and bad practise.

In the particular case where a data field is basically textual however it may be generated by a system that does not follow XML conventions, then this data type may be used.

In almost all cases in s3.18.96 and associated schema components, change the type to reference xsd:String instead of ST_Xstring. The normal XML restrictions will then apply. This must be done for all uses in names, titles, ids, numbers, formats, captions, etc.

(Where a data field is basically textual however it may be generated by a system that does not follow XML conventions, then this data type may be used.)

It is an Australian requirement that there should be no back doors for binary or encrypted or obfuscated data, and that only safe characters should be used.

This datatype directly goes against the efforts of Standards Australian delegates in the last decade, as promoted by ISO SC34, W3C, and the Unicode Consortium. See the W3C/Unicode document “Unicode in XML and other markup languages” http://unicode.org/reports/tr20/tr20-6.html

It is an Australian requirement that both display names and identifiers must conform to accessibility standards: in this case, to use graphical characters only.

AU

Part 4 s2.18.4

 

Ed te

It is inappropriate to have a fixed list of values, both because it is unnecessarily product-specific and because it creates a maintenance problem.

Furthermore, there appears to be a conflict between the schemas, which specific a closed (enumerated) list, and the text which mentions “possible enumerated values”. So it seems that the intent may have been to have an open list. In other similar cases in the same Part, string types are used rather than an enumeration, so this seems to be a mistake.

Furthermore, it is appropriate for information of this kind to be separated into an annex.

Alter the schema so that ST_Border uses the XSD token type.

Move DIS Part 4 s2.18.4 into a separate normative Annex: “Basic Border Types”. Rephrase the annex to say “The following border names are reserved by this standard.”

It is an Australian requirement that standards have clear conformance requirements.

AU

Part 4 s3.8.40 Table Styles

 

ed

The phrasing of this section is unclear, and there appears to be conformance requirements that go against the “purely syntactic” requirement of Part 1.

Furthermore, it is appropriate for information of this kind to be separated into an annex.

The meaning of the first paragraph is entirely unclear and needs to be rephrased.

Move all the built-in style definitions DIS Part 4 3.8.40 into a separate normative Annex “Basic Table Styles”. Rephrase the annex to say “The following style names are reserved by this standard.”

It is an Australian requirement that standards have clear conformance requirements.

AU

Part 2, s8.1.2

 

te

There is a security issue that the OPC relationships mechanism allows a kind of obfuscation that can hide virus or malware or unexpected objects from casual view and detection..

In particular, this is where objects with a .bin extension can be renamed to any other extension, such as .jpg or .txt, and potentially passed through a production process undetected.

However, DIS29600 does not specify a macro mechanism or Active X controls. Consequently it is difficult to add extra protection.

Add text to such as the following:

“It is a requirement of this standard that dynamic extension mechanisms such as scripting languages and macro mechanisms must use, for the executable parts and their “file extension”, the application/ content type tree, and must not use any of the application/ content types defined in this standard or file extensions belonging to other content types.”

It is an Australian requirement that simple forms of attack should be discouraged.

It is an Australian requirement that standards have clear conformance requirements.

AU

Part 2, s8.3.5

Para 2

ed

The meaning of para 2 is unclear. What is “ignored content” in this context.

It is strongly desired that any requirements in the specification which causes renaming and removal of parts be made user- and application- optional.

Clarify para 2. No concrete suggestion is possible in the absence of a clear understanding of the behaviour.

It is an Australian requirement that standards have clear conformance requirements.

AU

  Part 1, s 8.2

 

te

DIS currently allows applications to arbitrarily move and rename parts, providing the correct relationships are kept. However, this works against documents which are OPC-compliant and also contain data formats that do not use the OPC relationships system but hardcode locations.

For example, an OPC file that contains various JPEG images together with an HTML file that uses those images and the equivalent Open XML file. If the Open XML application renames the images, the HTML file will be out-of-date.

1.      Add  paragraph to DIS Part 1 s8.2 “A tool that acts both as a consumer and producer should not rename media files, at user option, unless the package has no unknown relationships.”

2.      Change any text relating to arbitrary renaming to make it strictly a user option, not the user default.

 

It is an Australian requirement that where there are multiple standards in the same space, these standard should not encourage application behaviour that gratuitously hinder future convergence or harmonization efforts.

One option for harmonization is that OPC files may contain multiple documents in different standard formats.