XXX Dette er et utkast som ikke er ferdig ennå XXX

How were Norway's OOXML comments handled?

This document describes the Norwegian comments on OOXML and how they were handled. The comments were sent to ISO in 2007. This document lists all the comments along with a summary of what was done (or announced to be done) to handle them.

The comments are [http://www.standard.no/pronorm-3/data/f/0/17/24/1_2401_0/2008-08-31_NO_ISO_IEC_DIS_29500_comments.pdf available as PDF] from Standard Norge. See also a [http://www.idg.no/computerworld/article62811.ece summary from Computerworld Norge] for some information on how the comments were described when they were sent to ISO, and the [http://people.opera.com/howcome/2008/ooxml/brev.html letter sent from several committee members] in from of the committee meeting 2008-03-28.

NO-01 The Scope clause in Part 1 is inappropriate for an ISO standard

Justification:

• The Scope clause is self-referential, does not convey any useful information, and does not conform to JTC1 and ISO Directives for the scope of a standard or NP (ref. JTC1 Directives, 6.2.1.6; ISO Directives, Part 2, 6.2.1 Scope). In the absence of an appropriate Scope clause it is not possible to resolve a number of issues arising from the current text.

Proposed change by the MB:

• BRThe Scope clause should be rewritten to give a succinct overview of the contents of the standard without self-reference, for example: BR"This International Standard specifies a set of XML vocabularies for representing legacy documents produced by MS Office applications. It covers word processing, spreadsheet, presentation and graphics documents produced by the following versions of MS Office applications: BR[list supported versions] BRIt does not cover documents produced by other office applications." BRThe exact form of the Scope clause will depend on what decisions are taken regarding the final structure of the standard (e.g. as a multi-part standard).

Change accepted in OOXML:

• Scope clause was changed and restructured. All parts of 29500 shall have the following clause:
  • "# Scope clause

    BRThis International Standard defines a set of XML vocabularies for representing word-processing documents, spreadsheets and presentations. The goal of this standard is, on the one hand, to represent faithfully the existing corpus of word-processing documents, spreadsheets and presentations that have been produced by Microsoft Office applications (from Microsoft Office 97 to Microsoft Office 2008 inclusive). It also specifies requirements for Office Open XML consumers and producers , and on the other hand, to facilitate extensibility and interoperability by enabling implementations by multiple vendors and on multiple platforms. BRThis part specifies concepts for documents and applications of strict and transitional conformance."

  In addition each part will have a sub clause specifying the exact scope for that part. In addition each scope clause shall have a reference to the informative specification of the following:
  • All XML elements which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
  • All XML elements which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
  • All XML attributes which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
  • All XML attributes which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
  • All enumeration values which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
  • All enumeration values which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
  • All simple types which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
  • All simple types which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
  The word "legacy" was not added to document that only old documents are handled by this specification, and the statement about other office applications was not added.

Conclusion:

• Hard to decide before we have the complete picture on the wording of the scope based on the new division of parts. It is also interesting to note that "existing corpus of word- processing documents, spreadsheets and presentations" does not include Microsoft office applications before Office 97. Part of the reasoning for this comment was to learn if the specification only should be used for legacy documents, and thus not compete with ODF on representing future documents, or if it also was to represent future documents. If it is to represent future documents, it should be rejected as it compete with ODF. The BRM did not want to limit the scope of the standard to representing legacy documents, and wanted it also to be used for new documents.

NO-02 Rework into a multi-part standard.

Justification:

• As currently drafted, DIS 29500 covers many areas that are not directly related to one another. This makes it difficult to review by National Body experts, difficult to implement, and difficult to assess compatibility.

Proposed change by the MB:

• Rework into an ISO-style multi-part standard along the following lines:
  1. Introduction
  2. Common/Core components and metadata
  3. WordprocessingML
  4. SpreadsheetML
  5. PresentationML
  6. Extensibility
  Each part should have its own Scope and Conformance clause. This would allow different parts of the standard to be used independently of each other. The Primer is informative and should be published as a Technical Report.

Change accepted in OOXML:

• The specification will be reorganised, but not along the lines of functionally similar sections.
  • The proposed parts are now 1) Fundamentals and Markup Language Reference, 2) Open Packaging Convention, 3) Markup Compatibility and Extensibility and 4) Transitional Features.

Conclusion:

• The specification was not changed in a way that allow different parts to be used independently of each other, and thus Norway's proposal was not implemented.

NO-03 Rework into a much more concise standard.

Justification:

• The text of DIS 29500 is too voluminous to be reliably reviewed by National Body experts, or for implementations to be assessed for compatibility. It appears to be unnecessarily long, combining normative text with copious examples and containing a lot of redundancy.

Proposed change by the MB:

• The text should be shortened considerably, through the removal of non-normative text (into annexes), the avoidance of redundancy and other means.

Change accepted in OOXML:

• As far as we know, no relevant change was done. Instead, adding 1400 pages of "collected XML syntax" was accepted as a change.

Conclusion:

• Hard to conclude since the new version of the standard is not available. But most likely our request on a more concise standard is not met, due to the fact that much information on deprecated features is moved into "Transitional parts of the document" this would most likely have the effect that the standard will be harder to read, since you need to check several places in the documentation to understand how to use the standard. This proposal is not satisfactory met

NO-04 The information model is unnecessarily complex.

Justification:

• The XML information model described is unnecessarily complex. Given the example in the Overview at page 13 (§5.6)

<w:p>
   <w:r>
     <w:t>Hello, world.</w:t>
   </w:r>
</w:p>

• Could - and should - be represented as:

<p>Hello, world.</p>

Proposed change by the MB:

• Simplify the information model and document structure, in order to ease implementation, interoperability and the processing of the OOXML documents. Where possible use notations in conformance with ODF.

Change accepted in OOXML:

• This change was rejected.

Conclusion:

• OOXML did not change according to the proposal from Norway.

NO-05 All examples should conform to the XML specification

Justification:

• More than 10% of the examples are not valid XML. This will cause confusion and could lead to differences in implementation that will inhibit interoperability.

Proposed change by the MB:

• All examples should be valid XML, except where there is an express intent to exemplify invalid data.

Change accepted in OOXML:

• This change was accepted.

Conclusion:

• OOXML was promised to change according to the proposal from Norway.

NO-06 DrawingML should be a separate standard

Justification:

• DrawingML has general applicability as an XML vocabulary for vector graphics. It should therefore be a standard in its own right that can be referenced in isolation by other ISO standards, such as ISO 26300.

Proposed change by the MB:

• Remove DrawingML from 29500 and propose it as a separate standard, or commit to doing so at a later stage.

Change accepted in OOXML:

• It is proposed that the following editorial change be made to the DrawingML specification:
  1. The DrawingML specification is to be reorganized into two sections
     1. DrawingML - Framework
     2. DrawingML - Components
  2. The following sections in the DrawingML specification will be moved into the "DrawingML - Components" section
     1. DrawingML - Paragraphs and Rich Formatting, Section 5.1.5
     2. DrawingML - Tables, Section 5.1.6
     3. DrawingML - Charts, Section 5.7
     4. DrawingML - Chart Shapes, Section 5.8
     5. DrawingML - Diagrams, Section 5.9
  3. All remaining sections of the DrawingML specification will be moved into the "DrawingML - Framework" section.

Conclusion:

• The sections on DrawingML were collected into a separate chapter, and some statements were made that this could be separated out at a later stage, but no commitment could be made about the work of a future group. Our request is not met. DrawingML was not proposed as a separate standard, and there was no commitment for doing so at a later stage.

NO-07 OPC should be a separate standard

Justification:

• The Open Packaging Conventions could support a much broader range of applications than OOXML. It should therefore be a standard in its own right that can be referenced in isolation by other ISO standards, such as ISO 26300.

Proposed change by the MB:

• Remove OPC from 29500 and propose it as a separate standard, or commit to doing so at a later stage.

Change accepted in OOXML:

• OPC is now a separate part of the standard, but not a separate standard. The claim was made that processing of a PAS, once entered, cannot result in creation of multiple standards.

Conclusion:

• Partially addressed. The norwegian proposal was to submit OPC as a separate standard proposal, not to use this PAS process to create multiple standards. Reusing OPC when it is a chapter in 29500 with possible references to the rest of 29500 will be harder than if it was a separate standard.

NO-08 The specification should not include binary notations

Justification:

• Unspecified (or underspecified) binary notations, especially those with operating system dependencies, inhibit interoperability and do not belong in an ISO standard. Even well-specified binary notations, such as bitmasks used to encode multiple boolean values, are inappropriate in an XML-based interchange format. Non-standard text-based encodings of control characters, such as 'bstr' (basic string) are also inappropriate.

Proposed change by the MB:

• All references to platform specific and/or binary notations, such as DEVMODE for printer settings and bitmasks for boolean values, should be removed and, where possible, replaced by open, XML-based standards, more explicit XML vocabulary, or base64 encoding.

Change accepted in OOXML:

• Some of the constructs pointed at were better documented.
• Some of the constructs were marked "transitional".
• The ability to include objects in undocumented binary formats was kept.
• DEVMODE was kept, and was not marked "transitional".

Conclusion:

• The comments have not been addressed.

NO-09 The specification should not contain underspecified features

Justification:

• Underspecified features and settings, such as "autoSpaceLikeWord95", "footnoteLayoutLikeWW8", "lineWrapLikeWord6", "mwSmallCaps", "optimizeForBrowser", "shapeLayoutLikeWW8", "supressTopSpacingWP", "truncateFontHeightsLikeWP6", "useWord2002TableStyleRules", "useWord97LineBreakRules", "useWord97LineBreakRules", "wpJustification", "wpSpaceWidth", "sldSyncPr", "securityDescriptor", and "revisionsPassword" preclude uniform implementation and thus inhibit interoperability.

Proposed change by the MB:

• All features should be specified in enough detail to enable uniform interpretation by multiple implementations. Those that cannot be specified in sufficient detail should be removed.

Change accepted in OOXML:

• Some (or all, have not checked all) of the underspecified features got more documentation, but the specifications checked so far was vague and not detailed enough for a developer to use it to get the same result without reverse engineering MS Word.

Conclusion:

• As the whole point of this comment was to ensure uniform interpretation by multiple implementations to make sure the OOXML documents are processed and displayed the same way in all implementations of OOXML, it is clear that OOXML was not changed according to this comment. We did not ask for more text, we asked for specification in enough detail to enable uniform interpretation by multiple implementations, and removal of all features lacking this.

NO-10 Option sets should be extensible and should avoid cultural bias

Justification:

• Options to features such as border styles, enumeration styles, list styles, the function NETWORKDAYS(), Clipboard Format Type, etc. should not exhibit cultural bias or be unduly restrictive, since this will inhibit adoption internationally.

Proposed change by the MB:

• All such features should be made extensible wherever possible and defined options should be specified in full in order to enable uniform implementation.

Change accepted in OOXML:

• New features were added that could do the functions pointed at in culturally acceptable ways.
• The current features were marked "transitional".

Conclusion:

• The committee attempted to address the issue, but the result was a more complex standard.

NO-11 OOXML should reference, use, and conform to existing standards where applicable

Justification:

• It has been claimed that the current standard conflicts with other ISO standards, such as ISO 8601 (Representation of dates and times), ISO 639 (Codes for the representation of names of languages) and ISO/IEC 10118-3 (Hash functions). If this is the case, the specification should be brought into line with these and other existing standards. The problem is especially apparent in the case of the 'date1904' attribute. The ambiguity regarding the status of the year 1900 should be resolved by using ISO standard dates everywhere.

Proposed change by the MB:

• Ensure that 29500 does not conflict with the above-mentioned standards and use only ISO standard date formats, not ambiguous numeric dates.

Change accepted in OOXML:

• The existing parts of the specification using a different date specification, language names and hash functions were kept. The use of ISO 8601 dates were added, thus forcing those implementing this specification to implement at least three different date formats, and some of them are not following the Gregorian calendar system. Similar was done for ISO 639, where both the original language definition was kept while it is also possible to use language codes from ISO 639, forcing implementations to handle two separate sets of language codes.

Conclusion:

• OOXML did not change according to the proposal from Norway.

NO-12 Lack of consistency in notation of values and dimensions

Justification:

• There is no coherent dimension notation throughout the specification, for instance the relative dimension "87,5%" is sometimes represented by "pct87", sometimes by "87500" or even by "4375". This will cause confusion and could lead to non-interoperable implementations.

Proposed change by the MB:

• Put in place a coherent value system.

Change accepted in OOXML:

• On percentages, the fields were changed to accept two different formats, the old format and a format that was a text string followed by a "%" (percent sign) character.

Conclusion:

• The specification still do not have a coherent value system. Length units, colour settings, etc are still represented using several different notations, making it very hard to implement the specification, leading to confusion and interoperability problems. Adding more type of values (as an extra notation for percent values) only increases the problem. OOXML did not change sufficiently according to the proposal from Norway to claim that this issue is solved.