Template for comments and secretariat observations Date: 2007-08-30 Document: ISO/IEC DIS 29500
 
1 2 (3) 4 5 (6) (7)
MB1 
Clause No./ 
Subclause No./ 
Annex 
(e.g. 3.1)
Paragraph/ 
Figure/Table/Note 
(e.g. Table 1)
Type of com-ment2 Comment (justification for change) by the MB Proposed change by the MB Secretariat observations 
on each comment submitted

NO [Part 1]  
1 and other parts.
  te Summary:

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.

The Scope clause should be rewritten to give a succinct overview of the contents of the standard without self-reference, for example:

"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:

[list supported versions]

It does not cover documents produced by other office applications."

The 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).

 
NO [ALL]   ed Summary:

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.

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.

 
NO [ALL]   ed Summary:

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.

The text should be shortened considerably, through the removal of non-normative text (into annexes), the avoidance of redundancy and other means.  
NO [Part 4]  
2-7
  te Summary:

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>

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.  
NO [ALL]   te Summary:

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.

All examples should be valid XML, except where there is an express intent to exemplify invalid data.  
NO [Part 1]  
8.6.1

[Part 4]  
5

  te Summary:

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.

Remove DrawingML from 29500 and propose it as a separate standard, or commit to doing so at a later stage.  
NO [Part 1]  
9.1

[Part 2]

  te Summary:

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.

Remove OPC from 29500 and propose it as a separate standard, or commit to doing so at a later stage.  
NO [Part 1] 15.2.14

[Part 4] 2.3.1.6, 2.4.51, 2.4.52, 2.4.7, 6.4.3.1, 7.4.2.4, 7.4.2.5, etc.

  te Summary:

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.

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.  
NO [Part 4]

2.15.2.32, 2.15.3.6, 2.15.3.26, 2.15.3.31, 2.15.3.32, 2.15.3.41, 2.15.3.51, 2.15.3.53, 2.15.3.54, 2.15.3.63, 2.15.3.64, 2.15.3.65, 2.15.3.9, 3.2.29, 3.3.1.69, 4.7.1, etc.

  te Summary:

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.

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.  
NO [Part 4] 2.18.4, 2.18.66, 3.17.7.224, 6.4.3.1, etc.   te Summary:

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.

All such features should be made extensible wherever possible and defined options should be specified in full in order to enable uniform implementation.  
NO [Part 4] 2.18.15, 2.3.2.18, 3.2.27, 3.17.4.1, etc.   te Summary:

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.

Ensure that 29500 does not conflict with the above-mentioned standards and use only ISO standard date formats, not ambiguous numeric dates.  
NO [Part 4] 2.18.85, etc.   ed Summary:

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.

Put in place a coherent value system.  

MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **)

2 Type of comment: ge = general te = technical  ed = editorial

NOTE Columns 1, 2, 4, 5 are compulsory.

page of 5

ISO electronic balloting commenting template/version 2001-10


Top