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

DE Part 1, Section 2.4 line 22 Ed This line require conformance with “Unicode Standard” without specifying a version.  XML 1.0 referred to Unicode 2.0, though the informative Appendix A of OOXML Part 1 lists Unicode 4.0.  Which is it? Although Annex A is informative, to be of any use (i.e. giving valuable information) it should still be consistent with the rest of the document.  
DE Part 1 behavior, implementation-defined Te “application-specific”, at least in common standards use, is not the same as application-defined, viz. ANSI C Programming Language Correct the consistence use of application-defind and application specific  
DE Part 1, Section 9.1.1 - Ed ASCII requires a normative reference since there are several national variations. Suggested reference be made to ISO/IEC 646:1983 or ANSI X3.4-1986  
DE Part 1, Section 9.1.5 - te This sub-clause, buried in introductory material, negates a provision of the more detailed OPC specification in Part 2.  This will likely be missed by implementors. If interleaving is not permitted then it should not be described in Part 2  
DE Part 1, Section 10.1.2 line 20 Ed Reference is made to material in Part 12, Clause 12.  Although a clause of that number does exist, it does not contain the material 10.1.2 references it for. Correct the reference to point to the correct clause.  
DE Part 1, Section 11.3.1 lines 15-17 te This is requiring that a conforming OOXML consumer also be able to understand a specified list of other document formats, including proprietary ones such as MHTML and RTF, and for conforming producers to understand how to convert these formats to OOXML. Review the example  
DE Part 1, Section 12.3.5 - te This binary part is said to be used for the storage of “arbitrary user-defined data”.  No further detail is given as to what user action would trigger the use of this “user-defined” data.  Without further definition, no interoperability of this feature is possible. Clarify definition  
DE Part 1, Section 15.2.6 - ed What is meant by “This part shall have no contents”?  Does this mean that there shall be nothing in the Zip file with the declared name?  Or does it mean that a zero- byte file shall be created with the declared name?  Or something else? Clarify the meaning.  
DE Part 1, Section 15.2.12 - Ed There is no reference made to a particular dated version of TrueType or OpenType specifications.  And if TrueType and OpenType differ, then there should be different ways to refer to them, rather than calling them both “application/x-font-ttf” Provide reference to intended specifications for TrueType and OpenType

If they are ISO standards, then give the ISO standard number, else provide a reference according to JTC1 Directives, Annex N, "The Normative Referencing of Specifications other than International Standards in JTC 1 International Standards"

 
DE Part 1, Section 15.2.14 - Te It is unsatisfactory to store printer settings in OS-dependent binary formats like DEVMODE structures.  This is a considerable security concern (DEVMODE structures are loaded directly into device driver memory), as well as lacking cross-platform adaptability.  There is also no interoperability with print settings as currently defined. Default DEVMODE stucture should be XML, optional within binary adressable by a unique identifier.

Or better 

Model device settings in XML for interoperability and platform neutrality. In any case, require a datatype or format identification for these settings like a MIME type or XML Namespace, so that a processing application can decide whether and how to interpret that information. Require applications to round-trip unknown device settings.

 
DE Part 1, Appendix - Ed The reference given for the Zip format does not provide a date or version, though this specification is frequently revised pkzip version must be defined  
DE Part 4, Introduction page vii, line 7 Ed Full compatibility of the proposed OOXML with any existing application is demonstrably unreachable (because the proposed OOXML explicitly gives up describing parts of what it aims to describe, e.g. Part 4 page 1378 lines 12-17). Rephrase the compatibility goal so as to make it realistic.  
DE Part 4, Introduction page vii, line 8 Ed A standard should not rely on existing applications and brands for its description. Remove the reference to Microsoft Office.  
DE Part 4, Introduction page vii, lines 7&8 Ed The use of  'large' into 'large existing investments in Microsoft Office documents' is a judgment call relying upon unsupported assertions. Remove 'large'.  
DE Part 4, Section 2.2 page 26, lines 27&28 Te The definition of 'story' is inappropriate. As far as OOXML documents are concerned, the use of a text editor enables any user to modify (type into) each and any region of any XML subpart of a document. Clarify the definition of 'story'.

The definition of "Story" is appropriate as it is the region of content (main document, comments, headers, etc.) within a document where user can type/modify information.  

 
DE Part 4, Section 2.2.1 page 27, lines 1&2 te Assuming that background be referring to the background of the document defined by one of its enclosing elements, assuming that the notion of document page and the notion of displaying be properly defined and that their definitions match commonly accepted ones, then the 'This background shall be displayed on all pages of the document, behind all other document content.' sentence makes unclear whether the total surface of a page must be filled with the background, or else how the subpart of the said surface can be determined. Clarify the definition of 'background'.  
DE Part 4, Section 2.2.1 page 27, lines 8&21 te Contradicting use of accent3 and accent5. Clarify the definition of 'background' information  
DE Part4, Section 6.1 page 4343, lines 11&12 te OOXML states that VML should be considered as deprecated. A new standard should not contain deprecated parts. VML remains in the standard for compatibility reasons. However, new documents shall not use VML.  VML shall be used only for backward compatibility reasons to enable the migration of older documents to Open XML. One possibility would be to move VML to a separate section as an informative annex  or save as part  
DE Part 4, Section 2.2.1, 2.3.3.19, 2.3.3,

6.1,

6.2,

6.3,

6.4,

6.5

page 28, line 0

page 262, line 1

page 264, line 19

page 805, line 1

page 4753, lines 18&19,

page 4902, lines 8&9,

page 4920, lines 20&21,

page 4958, lines 6&7

te The reference to the urn:schemas-microsoft-com:vml namespace references VML, which is considered as deprecated (Part 4, page 4343, lines 11&12). A new standard should not contain deprecated parts. VML remains in the standard for compatibility reasons. However, new documents shall not use VML.  VML shall be used only for backward compatibility reasons to enable the migration of older documents to Open XML. One possibility would be to move VML to a separate section as an informative annex  or save as part  
DE Part4, Section 6. pages 4343-4960 te All subsections of Section 6 describe deprecated only material, making Section 6 deprecated as a whole. A new standard should not contain deprecated parts. VML remains in the standard for compatibility reasons. However, new documents shall not use VML.  VML shall be used only for backward compatibility reasons to enable the migration of older documents to Open XML. One possibility would be to move VML to a separate section as an informative annex  or save as part  
DE Part 4, Section 2.2.1 page 28, line 0 te The reference to the 6.2 subclause references VML, which is considered as deprecated (Part 4, page 4343, lines 11&12). A new standard should not contain deprecated parts. VML remains in the standard for compatibility reasons. However, new documents shall not use VML.  VML shall be used only for backward compatibility reasons to enable the migration of older documents to Open XML. One possibility would be to move VML to a separate section as an informative annex  or save as part  
DE Part 4, Section 2.2.1 page 28, line 0 te Child elements of background are described using deprecated namespaces only. Accordingly, the background element should either be described in terms of current OOXML elements or deprecated. VML remains in the standard for compatibility reasons. However, new documents shall not use VML.  VML shall be used only for backward compatibility reasons to enable the migration of older documents to Open XML. One possibility would be to move VML to a separate section as an informative annex  or save as part  
DE Part 4, Section 2.2.1 page 28, line 1 ed The sentence 'This color may either be presented as a hex value (in RRGGBB format)' does not make proper reference to a well accepted color description system. The text should be clear which colorspace is intended here.  
DE Part 4, Section 2.2.1 page 28, line 1 ed The sentence 'or auto to allow a 
consumer to automatically determine the background color as appropriate.' does not define the appropriate behavior of the consumer, whereas the definition of the corresponding simple type, found in Part 4, page 1737, explicitly states that 'This value shall be used to specify an automatically determined color value, the meaning of which is interpreted based on the context of the parent XML element.'
Define the characteristics of the auto value for the color attribute of the background element properly.  
DE Part 4, Section 2.2.1 page 28, line 1 ed The definition of the themeColor attribute references the document's Theme part without properly defining it nor providing an explicit reference to the OOXML section that defines it. Define the Theme part of a document properly or else add an explicit reference to the section that does so.  
DE Part 4, Section 2.2.1 page 28, line 1 ed The sentence 'the color resulting from the use of this attribute with any appropriate themeTint and themeShade attribute value calculations applied' somewhat contradicts the first sentence of the definition for themeColor. So suggested is to rewrite this sentence as: "If the color attribute is specified, its value shall be ignored in favor of the color resulting from the use of the themeColor attribute with any appropriate themeTint and themeShade attribute value calculations applied."  
DE Part 4, Section 2.2.1 page 29, line 0 ed There are several instances of the word 'border' that are meaningless in this context (the text is supposed to describe the 'background' element at that location). Clarify which border the text refers to (if any notion of border must be introduced here) or else rewrite the text so that it makes sense.  
DE Part 4, Section 3.17.4 page 2522 te The proposed date and time system makes no reference to ISO 8601, and is markedly different from it. This is supported by no explicit and acceptable reason. Introducing brand new conventions where established standards exist is costly and brings no value to the public. Moreover, it brings confusion, and compels application implementors to add converters. Replace the proposed date and time system by ISO 8601.

Proposed resolution:    DIS  29500 should be augmented by the possibility to enter other dates and introduce a Boolean variable that indicates how to treat the leap year calculation (Excel already provides this function as a consumer)

 
DE Part 4, Section 3.17.4 page 2522, lines 7&8 ed The 'As dates and times are numeric 8 values, they can take part in arithmetic operations' sentence is misleading, since arithmetics on dates and times is ill-formed except for very narrow cases (mainly duration, with restrictions though). Explain the relationship between dates, times and calendars and warn that dates arithmetics is misleading, or drop the sentence altogether.  
DE Part 4, Section 3.17.4.1 page 2522, lines 14-18 te The text proposes a dual date base system. There is no clear advantage to having two slightly different systems, and this brings significant costs and confusion, as illustrated by the need to specify a default base system, etc. Choose and keep a single date system.

Proposed resolution:    DIS  29500 should be augmented by the possibility to enter other dates and introduce a Boolean variable that indicates how to treat the leap year calculation (Excel already provides this function as a consumer)

 
DE Part 4, Section 3.17.4.1 page 2522, lines 19 te The proposed date system does not cope with dates anterior to 1900-01-01. Propose a better date system.

Proposed resolution:    DIS  29500 should be augmented by the possibility to enter other dates and introduce a Boolean variable that indicates how to treat the leap year calculation (Excel already provides this function as a consumer)

 
DE Part 4, Section 3.17.4.1 page 2523, lines 1-6 te The 1900 date base system is bogus, according to the OOXML text itself. A standard should not deliberately include bogus features. Remove the 1900 date base system or reform it.

Proposed resolution:    DIS  29500 should be augmented by the possibility to enter other dates and introduce a Boolean variable that indicates how to treat the leap year calculation (Excel already provides this function as a consumer)

 
DE Part 4, Section 3.17.4.1 page 2522, lines 16&18 te The documented upper limits for serial date times match 9999-12-31 00:00:00, which is most probably not what was intended. The expected upper limits would match 9999-12-31 23:59:59. It is true that 2,958,465 matches 9999-12-31.  But it is false where the text says that this is the upper limit and that, "A serial value outside of the range for its date base system is ill-formed."

Specifically, all hours of 9999-12-31 are allowed, so a serial values of 2,958,465.999999 is also allowed.

 
DE Part 4, Section 2.18.51 page 1747, line 18 te The use of an union for the ST_Lang type only brings extra costs and confusion, and should be replaced by a single representation that leverages the appropriate standards. In the case of language tags and other such closed lists, DIS29500 should be extended to replace closed lists with open lists that can accept values of existing standards (e.g. ST_Lang should reference BCP47 for language tags). Other closed lists should also be studied to consider opening their values to existing standards.  
DE Part 4, Section 2.18.51 page 1747, line 19 te OOXML relies upon ISO 639-1 for languages description. ODF 1.0, ISO/IEC 26300:2006 relies upon ISO 639, which is more complete (aka chy) for the same purpose. The use of ISO 3166 only brings a country code, which is not enough to map all existing entries of ISO 639-2 upon ISO 639-1. Moreover, ISO 639-3 was adopted as an ISO standard since 2007-02-05, making an explicit reference to ISO 639-2 problematic.

"Contradictions to existing standards, particularly in relation to ISO 216 (paper size) and ISO 639 (language identifiers)."

Additional: Numeric enumerations for language/country (p. 1748ff) or paper sizes (p. 1988ff) make interoperability unnecessarily complicated because all consuming applications (at least) must know these OOXML-specific numeric constants. The comment might be addressed by suggesting that the specification should only use the alphabetic codes (ISO639/3166) and drop the hexcodes completely or, for paper sizes, use "speaking" alphnumeric codes (like "A4") instead of "cryptic" numerical constants (like "9").

In the case of language tags and other such closed lists, DIS29500 should be extended to replace closed lists with open lists that can accept values of existing standards (e.g. ST_Lang should reference BCP47 for language tags). Other closed lists should also be studied to consider opening their values to existing standards.

This considers as well to the expression of papersize

 
DE Part 4, Section

2.15.3

2.15.3.6,

2.15.3.16, 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.66

page 1378, lines 12-17,

page 1416, lines 14-17

page 1426, lines 11-16

page 1427, lines 13-18

page 1442, lines 13-18

page 1462, lines 11-16

page 1467, lines 9-14

page 1482, lines 10-15

page 1483, lines 16-21

page 1481, lines 9-14

te The <INSERT_ELEMENT_NAME_HERE>  element, which is defined in terms of mimicking a legacy application's behavior.  The standard contains insufficient detail on how to replicate this behavior.

For e.g. “autoSpaceLikeWord95”, “footnoteLayoutLikeWW8”, “lineWrapLikeWord6”, ..., "doNotLeaveBackslashAlone" (page 2180)

In General: These “compatibility” settings solve no general problem.  They are merely a museum of settings from previous versions of Microsoft Word.  No allowance has been made for legacy settings from other applications.  Better to have these be application-specific settings using the existing extensibility mechanisms of OOXML

There are more than 200 compatibility settings that are fully documented in Ecma-376. There are less than a dozen for which additional clarification has been requested. DIS 29500 should provide more information about the behavior of those dozen of compatibility settings. In case an acceptable description is too difficult to provide, the associated compatibility setting should be removed from DIS 29500.  
DE Part4, Section 2.16.5.40 page 1544, line 2 ed The results as displayed in this table contradict the definition of LISTNUM as specified page 1542 line 12 (neither 'a' nor 'iii' are numbers). Fix the contradiction.  
DE Part4, Section 2.16.5.40 page 1544, line 2 ed The values given in the table make no sense. Most probably, 'iii' instances stand for 'i' instances. Specify proper values.  
DE Part4, Section 2.16.4.3 page 1501, line 0 ed The definition for BATHTEXT references 'the given Thai format', which makes no sense in the context of that definition. The text says, "Formats a numeric result using the given Thai style."  The question remains "what given format"?  The use of the word "given" suggests that a format is being passed in and that the request is not only to format it in Thai, but in the "given Thai format" (one of several possible Thai formats).  The text must be clarified.  
DE Part4, Section 2.16.5.5 page 1512, lines 11-12 ed According to the text, the AUTONUM field is deprecated. A new standard should not contain deprecated parts. Review 'AUTONUM' in the context of 'LISTNUM'. Deprecated content shall not be part of the specification  
DE Part4, Section 2.16.5.40 page 1543, line 12&13 te The definition for 'LISTNUM' is built upon the concepts of 'current' or 'specific' or 'next series', which are not defined in this context (a backward search on 'series' sheds no light on this). Those concepts should be defined in the text, and their definition should either be copied or referenced in the context of the definition for 'LISTNUM'. The LISTNUM definition shall be redefined for clarity.  
DE Part 1, Section 2. page 1, line 6 ed The definition for the use of 'shall' in the OOXML text is specific to the OOXML proposition. Its relationship to the use of 'shall' as defined in ISO/IEC 
Directives, Part 2 - Rules for the structure and drafting of International Standards - Fifth edition, 2004, Annex H, should be clarified and documented in the text. Our understanding is that the OOXML definition is compatible with the ISO one, but the latter is more precise and any ambiguity on this point should be removed. Moreover, its use in the OOXML text should be aligned with the ISO requirements wherever this is possible.
Clarify the relationship between Open XML and ISO definitions for the use of 'shall' and review the text by using a unique definition  
DE Part 4, Section 2.16 page 1487, line 20 te Except if a clear definition of 'field update' would be provided that would clearly show the innocuousness of this, we would expect the exclusion of the how and when it happens from the OOXML proposal to be abusive. ‘field updates’ shall be carried out such that the field value reflects dynamic data correctly, the exact decisions that cause field updates are application defined. Exceptions should be documented in the definition of the field.  
DE Part 4, Section 2.16.4.3 Page 1501 ff te The use of different notations for the 'INSERT FIELD NAME HERE' switch argument and the 'INSERT FIELD NAME HERE' ST_NumberFormat enumeration value is useless and confusing.

f.e.g. ‘AIUEO’, ‘ARABICABJAD’, ...

Re-write part 4, section 2.16 of the OpenXML specification using XML constructs as much as  possible in order to remove redundancy and improve re-use of other parts of the specification (i.e. number-, text- date- and time-formatting).  
DE Part 4, Section 2.16.4.3 page 1501, line 0 ed The BAHTTEXT switch argument has no documented ST_NumberFormat equivalent. This shades doubt upon the value of the switch argument, or else a potential hole in ST_NumberFormat values. Insert reference to ST_NumberFormat equivalent 'thaiCounting' and vice versa  
DE Part 4, Section 2.16.4.3 page 1501, line 0 ed The CHARFORMAT switch argument definition should be simple enough to fit in the table. Reading the discussion referenced in this table row, we understand that the CHARFORMAT behavior is inherently complex, more complex than other switch arguments. Accordingly, we question its status as a number formatting argument. Rephrase the definition by using less ambiguous wording  
DE Part 4, Section 2.16.4.3 page 1501ff te The CHARFORMAT, KANJINUM1, KANJINUM3, MERGEFORMAT, .. switch argument has no documented ST_NumberFormat equivalent. This shades doubt upon the value of the switch argument, or else a potential hole in ST_NumberFormat values. Create a ST_NumberFormat value that matches the CHARFORMAT, KANJINUM1, KANJINUM3, MERGEFORMAT, ... switch argument or (better) suppress the need for the switch argument, either by using an ST_NumberFormat type in a proper XML notation for number formats in the context of fields, or simply by suppressing it from the OOXML proposal altogether.

Merging the ST_NumberFormat and Formfield number definitions in one table to clarify the references

 
DE Part 4, Section 2.16.4.3 page 1506, line 36 to page 1507, line 28 te The MERGEFORMAT switch argument is clearly a (complex) shorthand notation for something that could be described unambiguously by other OOXML notations, for example by a consistent use of the r:rPr element. In the current state of its definition, it has the bizarre property to give a regular XML element (r:rPr) the status of 'consider', while the absence of MERGEFORMAT would imply that the r:rPr be ignored, which we consider as badly designed (if the r:rPr element had to be ignored, it would be better to omit it altogether). We thus tend to recommend that the a proper use of r:rPr be considered and that MERGEFORMAT be removed. Re-write part 4, section 2.16 of the OpenXML specification using XML constructs as much as  possible in order to remove redundancy and improve re-use of other parts of the specification (i.e. number-, text- date- and time-formatting).  
DE Part 4, Section 2.16.4.3 page 1505, line 2 to page 1506, line 35 te The CHARFORMAT switch argument is clearly a (complex) shorthand notation for something that can be described unambiguously by other OOXML notations. Moreover, it overloads those notations and is superseded by them when a conflict occurs. As such, it must be seen as an input device, not as a document storage feature, and should be removed. Re-write part 4, section 2.16 of the OpenXML specification using XML constructs as much as  possible in order to remove redundancy and improve re-use of other parts of the specification (i.e. number-, text- date- and time-formatting).  
DE Part 4, Section 2.16.5 page 1509, line 0 te The definition of 'User Information' implies that the document user be known at all times and reflected in the document contents (by magic?), which is obviously not operable. There may be a hidden reference here to a particular user? Clarify the description of 'User Information'.  
DE Part 4, Section 2.16.5.1 page 1509, lines 4&5 te The definition of 'ADDRESSBLOCK' is tautological. Nothing here defines what an address block is, neither what it contains. No reference to a remote definition is provided either. Define ADDRESSBLOCK properly, either in extenso or by reference, or else remove all references to it from the OOXML text.  
DE Part 4, Section 2.16.1 Syntax page 1487, line 23 to page 1489, line 17 te The syntax of fields is defined using an unspecified notation, that appears to borrow some characteristics of Backus-Naur form for grammar productions, some notations from popular ways of specifying command line applications options, etc., all without the needed rectitude to define the notation used. In any case, the notation used should at least be referenced without ambiguity, and the proposed definitions should be reviewed for conformance to the said notation. Re-write part 4, section 2.16 of the OpenXML specification using XML constructs as much as  possible in order to remove redundancy and improve re-use of other parts of the specification (i.e. number-, text- date- and time-formatting).  
DE Part 4, Section 2.16.5.1 page 1509, line 6 te Definitions of \c and \e are inconsistent. More specifically, the definition of \c is broken by the fact that 'the value for \e' is undefined if there are multiple \e instances provided. Improve the definition of the \c and \e switches:

1. specify if multiple \e switches are allowed.

2. if that is the case, specify the behaviour of \c in the presence of multiple \e switches.

 
DE Part 4, Section 2.16.5.1 page 1509, line 6 ed The definition of the \d switch refers two undefined behaviors. As such, it brings no value at all. Reference relevant Universal Postal Union Guidelines for the formatting of addresses.  
DE Part 4, Section 2.16.5.1 page 1509, line 6 te The definition of the \f switch makes no sense at all in the context of the OOXML text. The mechanism for specifying the address template must be defined  
DE Part 4, Section 2.16.5.1 page 1509, line 6 ed The definition of the \l switch makes two references to 'Language ID', which is an undefined concept. Specify the List of supported Language Ids or supply a reference.  
DE Part 4, Section 2.16.5.2 page 1509, lines 10-12 te The definition of 'ADVANCE' is tautological. The implicit page rendering model it leverages is not defined. No reference to a remote definition of it is provided either. Clarify the description of advance to make clear whether lexical or presentation ordering should be used to determine the content affected by ADVANCE.  
DE Part 4, Section 2.16.5.2 page 1509, line 11 ed There is no way for text to overlap in an XML file, which makes the 'The switches used by this field can cause text to overlap' sentence meaningless. Remove or rewrite that sentence.  
DE Part 4, Section 2.16.5.2 page 1510, line 10 ed Considering together 'text that follows the field' and the syntax given line 9, the text being referred to should be the reminder of the document? This does not make much sense, and is not consistent with the examples given page 1510 lines 2&3. The definition of ADVANCE is inconsistent or broken even. This is just a typo which can be corrected on preparation of a final Specification document  
DE Part 4, Section 2.16.5.* page 1510 ff. te The syntax for <INSERT FIELDNAME HERE> is not compatible with the syntax of fields as provided on pages 1488&1489.

f.eg. ‘ASK’, ‘EQ’, ‘GOTOBUTTON’, ‘IF’, ..

The syntax must be reviewed and corrected to formally allow the definitions.  
DE Part 4, Section 2.16.5.3 page 1510, lines 15&16 te The 'Prompts the user to enter information' expression explicitly references a runtime behavior, which is out of the documented scope of the OOXML proposition, and not operable as far as a document storage format is concerned. The resulting definition for 'ASK' is broken. It shall  be clarified what is in the scope of Open XML, describing application behaviour or not describing it? It shall be used consistent within the spec.

Define 'ASK' properly or else remove all references to it from the OOXML text.

 
DE Part 4, Section 2.16.5.3 page 1510, lines 14 te The 'the bookmark designated by field-argument-1' expression refers to concepts that are not defined in the context where it occurs, neither explicitly, nor by reference. It shall  be clarified what is in the scope of Open XML, describing application behaviour or not describing it? It shall be used consistent within the spec.

Define the 'the bookmark designated by field-argument-1' expression either in extenso or by reference to a proper definition.

 
DE Part 4, Section 2.16.5.3 page 1510, line 16 te The 'The prompt is displayed each time the ASK field is updated' sentence explicitly places requirements on compliant applications with respect to their dynamic behavior related to field updates, at lest in the case of the 'ASK' field, whereas the text page 1487, line 21 explicitly excludes the how and when of field updates from the specification. It shall  be clarified what is in the scope of Open XML, describing application behaviour or not describing it? It shall be used consistent within the spec.

‘field updates’ shall be carried out such that the field value reflects dynamic data correctly, the exact decisions that cause field updates are application defined. Exceptions should be documented in the definition of the field.

Resolve the contradiction.

 
DE Part 4, Section 2.16.5.3 page 1510, lines 16&17 te The sentence 'A response remains assigned to the bookmark until a new response is entered' makes no sense at all in the context of an XML storage format. Any text editor or other compliant application could modify any fragment of an OOXML document at any time. The resulting definition for 'ASK' is broken. It shall  be clarified what is in the scope of Open XML, describing application behaviour or not describing it? It shall be used consistent within the spec.

Define 'ASK' properly or else remove all references to it from the OOXML text.

 
DE Part 4, Section 2.16.5.* page 1516 ff. te The text page 1487 lines 17-21 provides the formal definition for fields, and a formal definition for 'field result' and 'field update'. The OOXML text gives no formal definition for what a 'field value' might be. Accordingly, the relationship of the 'Field value:' item of this line to defined terms should be clarified, or else the definition of 'INSERT FIELDNAME HERE' must be considered as broken.

e.g. ‘ADDRESSBLOCK’, ‘BARCODE’, ‘BIBLIOGRAPHY’, ...

The concept "field value" shall be defined.  
DE Part 3, Section 8.3.4.1.1 page 456, line 1 ed The provided syntax is not a well-formed XML fragment. Therefore the definition of extLst is broken. A ‘ /’ is missing to close the XML fragment  
DE Part 4, Annex C. page 5205, line 3 and page 5205, line 5&6 ed The 'the set of XML Schemas included in Annex A' sentence is abusive. Annex A merely references material, it includes none. The verbiage of this section touts that the constraints that bear upon what the OOXML text would consider as valid XML documents are defined by the OOXML text, which they are not. Define properly, in extenso or by reference to a standard, the constraints that must be applied to an XML document to determine whether or not it is compliant with the proposed OOXML standard.  
DE Part 4, Section 2.16.1 Page 1489, line 17 ed 'Latin letters' is rather lax and cannot support the proper definition of a formal language. Rewrite this rule with a proper definition of its constituents (either by reference or in extenso).

e.g. [A-Za-z][A-Za-z]

 
DE Part 4, Section 2.16.5.12 page 1518, line 22 te The 'A paragraph number' expression is lax. Define what the field value, whatever field value may stand for, is in unambiguous terms.  
DE Part 4, Section 6.1.2.1 page 4362, line 0 ed The description of the 'style' attribute merely states that it 'uses the syntax described in [an external document]'. Either the syntax is defined by the said external document, or else the OOXML text must define it by itself. Define properly, in extenso or by reference to a standard, the 'style' attribute.

DIS  29500 should provide a list of normative references as expected

 
DE Part 4, Section 2.16.1 page 1489, line 2 ed We would not expect '” text' or 'text “' to be legit productions for 'field-argument'. Assuming that square brackets denote optional parts in this context, those would be accepted by the provided syntax though. The slightly peculiar expression [ " ] text [ " ] only saves one single line. We do not see any use in saving one line by introducing the need for an implicit understanding of any reader that "text appears either enclosed by double quotes or not enclosed by double quotes". That could easily be expressed by having one option with and one without double quotes.  
DE Part 4, Section 3.17.4.1 - te The restriction to only two date bases is arbitrary and based only on one vendor's applications.  There are other reasonable values for date bases, including earlier ones for historical dates. Allow a range of vendor-declared date bases, or explicitly allow negative date serial values to express dates prior to 1900

Proposed resolution:    DIS  29500 should be augmented by the possibility to enter other dates and introduce a Boolean variable that indicates how to treat the leap year calculation (Excel already provides this function as a consumer)

 
DE Part 4, Section 3.17.7.341 - te As written this function mandates an incorrect calculation for day of week for certain dates in the year 1900.   An ISO standard should not be mandating incorrect values for the well-established Gregorian Calendar.  To do so will only lead to confusion, poor interoperability and  perpetuation of errors. Remove the text that defines behavior that results in incorrect date calculations.

Proposed resolution:    DIS  29500 should be augmented by the possibility to enter other dates and introduce a Boolean variable that indicates how to treat the leap year calculation (Excel already provides this function as a consumer)

 
DE Part 4, Section 2.18.66 - te There is nothing in this section which is normatively defined except some enumeration values.  No normative meanings to these values are given.  An informative example is insufficient in all but the most trivial cases.  For example, where is “Korean Legal Counting System” defined? Give explicit definitions of these numbering styles or proper external normative references.  
DE Part 4, Section 2.18.66 “chicago” ed Format is defined in reference to the “Chicago Manual of Style”, but no edition or page reference is provided. Either include the entire definition in the standard, or provide a proper external reference.

DIS  29500 should provide a list of normative references as expected

 
DE Part 4, Section 2.18.66 “decimalEnclosedFullstop” ed The example given does not show enclosed characters and so contradicts the normative text. Reconcile the text and the example.

This is just a typo which can be corrected on preparation of a final Specification document

 
DE Part 4, Section 2.18.66 “decimalFullwidth”, etc. te There are several mentions of double-byte and single-byte Arabic numbering schemes.  Since the conformance clause for OOXML requires the use of Unicode in UTF8 or ITF16 encodings, there should be no mention of other encodings. Reconcile the text and the conformance clause..  
DE Part 4, Section 2.18.66 “lowerLetter”, etc. te Several counting systems are defined to use letters of the alphabet, but nothing is mentioned about how counting continues once the letters of the alphabet are exhausted. Clarify the text to explicitly cover this case.  
DE Part 4, Section 2.18.66 “numberInDash”, etc. ed Format requires use of “dash” to surround the number, but no indication of which Unicode dash is intended, en-dash, em-dash, hyphen-minus, figure-dash, quotation-dash, etc. If hyphen-minus is intended, it should be stated.  
Searching for hyphen-minus only shows a specification of element "softHyphen". One cannot find the explanation from the answer. If the meaning of "dash" actually is as described then it should be stated in the specification, too. This is at least an editorial issue. If not fixed this becomes a possible source of misinterpretation.
 
DE Part 4, Section 2.18.66 - te The formatting system described here is not comprehensive, lacking, for example, support for Armenian, Tamil, Greek alphabetic, Ethiopic and Khmer numerations, all in use today, as well as the various historical systems still used by scholars. Use a more flexible, extensible, generative approach to numeration, such as that used by the W3C's XSLT standard in their xsl:number support  
DE Part 4, Section 6.4.3.1   te The allowed values of this enumeration, EMF, WMF, etc., are Windows-specific formats.  No allowance seems to have been made for use by other operating systems.  For example, in Linux images are typically copied on the clipboard in an open standard format like PNG. Several options here, but the desire is to allow cross platform interoperability.

Proposed resolution: In the case of language tags and other such closed lists, DIS29500 should be extended to replace closed lists with open lists that can accept values of existing standards (e.g. ST_Lang should reference BCP47 for language tags). Other closed lists should also be studied to consider  opening their values to existing standards.

 
DE Part 4, Section 6.4.2.10 - te This element is defined as providing a, “general-use element for objects  that use an image representation, such as OLE objects, embedded controls, cameras and signature lines.”  However, the allowed values, EMF, WMF, etc., refer to formats for which no reference has been given. Provide a proper external normative reference for the allowed formats containable within this element.

Proposed resolution: In the case of language tags and other such closed lists, DIS29500 should be extended to replace closed lists with open lists that can accept values of existing standards (e.g. ST_Lang should reference BCP47 for language tags). Other closed lists should also be studied to consider  opening their values to existing standards.

 
DE Part 4, Section 7.4.2.5 - te This element defines values for use on Windows and Macintosh platforms, but not for Linux or any other operating system. Several options here, but the desire is to allow cross platform interoperability.

Proposed resolution: In the case of language tags and other such closed lists, DIS29500 should be extended to replace closed lists with open lists that can accept values of existing standards (e.g. ST_Lang should reference BCP47 for language tags). Other closed lists should also be studied to consider  opening their values to existing standards.

 
DE Part 4, Section 7.4.2.5 - te Even within a single platform, there is not enough information given to achieve interoperability.  For example, what are the allowed values and meanings for a “built-in Windows clipboard format value”? Specify this so interoperability may be achieved.

Proposed resolution: In the case of language tags and other such closed lists, DIS29500 should be extended to replace closed lists with open lists that can accept values of existing standards (e.g. ST_Lang should reference BCP47 for language tags). Other closed lists should also be studied to consider  opening their values to existing standards.

 
DE Part 4, Section 7.4.2.5 - ed The value of -3 specifies a GUID that contains a format identifier (FMTID).  The required format for neither a GUID nor a FMTID is specified. Part 4 Section 7.5.3.1 defines ST_Guid (128-Bit GUID Value) and its format. In the Section , the subject of this comment it is missing the reference to Section 7.5.3.1  
DE Part 4, Section 7.4.2.5 - te It doesn't make sense for us to be specifying strings as null-terminated C-style strings and then to base-64 encode that.  That is avoiding XML and will cause the markup to interoperate poorly with XML-based tools. Ecma should rethink the entire Clipboard Data representation.  It looks very much like it is mapping directly to the arbitrary internals of a single application.  This clause should be rewritten to express this feature in an application and platform neutral way.  
DE Part 4, Section 7.1 - te This is the specification of Office Open Math Markup Language, a specialized XML vocabulary for the describing the layout of mathematical equations.  This solves the same problem as MathML, a long-established W3C standard and an ongoing activity in the W3C.  Since the equation editing feature of Word was entirely rewritten in Word 2007, there doesn't not seem to be the argument that an additional equation language must be introduced for the sake of legacy documents. We request that MathML be explicitly allowed as an alternative to Open Math Markup everywhere where in the schema where OOXML currently allows OMML.  This way vendors and users can choose which they want to use.  
DE Part 4, Section 2.15.1.28 line 13 te This algorithm description fails to specify the encoding of the input password.  Presumably it is Unicode, but in what encoding?  UTF-16BE?  UTF-16LE?  UTF-16 with a BOM (Byte Ordering Mark)?  The described algorithms make use of byte-level manipulations which depend on the machine architecture (big endian versus little endian).  So it is necessary that all byte ordering assumptions be made explicit. The specified algorithm can be executed without kowledge of byte ordering. The phrase "Get the single-byte values by iterating through the Unicode characters of the truncated password.

For each character, if the low byte is not equal to 0, take it. Otherwise, take the high byte" specifies how to construct a byte array from a character string in a way independent of the byte order. The phrase might be clarified as "For each character, if the low byte of the Unicode code point of that character is not equal to 0, take it and drop the high byte (regardless of its value). Otherwise, take the high byte". It is unspecified how to deal with code points beyond U+FFFF and with combining characters. (The overall quality of the algorithm, however, is an entirely different matter.) In the recommendation, with PIs, do you mean XML Processing Instructions? If yes, how should these be used here?

 
DE Part 4, Section 2.15.1.29 - te This element allows the classification of the document into one of three types: “letter”, “email” or “general”.  Although the description says that this feature can be used by, “hosting applications to facilitate customized user interface and/or automatic formatting behaviors based on the 'type' of a given WordprocessingML document”, the taxonomy provided is so weak as to be practically useless. Provide a reasonable document type taxonomy, or loosen the type to an xsd:string to allow applications to provide their own or provide  alternative solutions to solve the problem for other vendors  
DE Part 4, Section 3.3.1.69 - ed No normative description of the password hashing algorithm is provided, so interoperability of this feature cannot be assumed.  In an informative section, C-language source code is provided as “an example”, and this appears to involve machine-dependent bit manipulations. The normative description is in §4:2.15.1.28 and should be referred to explicitly at this point of the specification.  
DE Part 4, Section 3.3.1.69 - te The securityDescriptor attribute, “defines 
user accounts who may edit this range without providing a password to access the range”.  It is a string.  But no information is given as to what user accounts are referred to here, or what the delimiter is.  Are these comma-delimited local machine user accounts?  Or semi-colon delimited LDAP DN's?  There will be no interoperability if this is not defined.
Define how the accounts are delimited to ensure interoperability  
DE Part 4, Section 3.2.29 pg. 1916 te This algorithm description fails to specify the encoding of the input password.  Presumably it is Unicode, but in what encoding?  UTF-16BE?  UTF-16LE?  UTF-16 with a BOM (Byte Ordering Mark)?  The described algorithms make use of byte-level manipulations which depend on the machine architecture (big endian versus little endian).  So it is necessary that all byte ordering assumptions be made explicit. Make the byte ordering assumptions explicit, both for the input password and the processing steps, so as to allow cross-platform interoperability.  Keep in mind that the hash may be calculated on a different machine architecture than the password was entered with.  
DE Part 4, Section 2.18.52 - te This type is defined as containing, “a two digit hexadecimal language code”.  It is further stated that, “This simple type's contents must have a length of exactly 2 characters”.  However, two hex digits can count up to 255 and the values enumerated in this clause go far beyond that. Reconcile the description of the type with the enumerated values.  
DE Part 4, Section 2.18.4 -   The artwork provided here is of poor quality providing neither intended scale, spacing, color depth, etc.  A small example diagram is an insufficient definition.  For example, are the dimensions of the borders absolute?  Or do they scale with page size?  Also, some of the images, such as 'apples' or 'balloons3Colors' show copying artifacts, where extraneous lines or blotches appear. Proposed resolution: Part 4, section 2.18.4 states:   “Art borders, which specify a repeated image to be used when drawing a border around the specified object.”   The art borders are images. Their size can only be changed but not the color depth etc as in case of any other image.   The dimensions of the border are absolute with respect to page size.    The extraneous lines or blotches can be corrected on preparation of a final Specification document. If there is any way to specified it in a way that allows a proper reproduction by any conforming consumer, it should be done.  
DE Part 4, Section 2.18.4 - te No mechanism for expanding the set of art borders is provided.  Since the specified art borders are heavily Western-oriented, it would be good to provide a way for an application to supplement these styles with graphics that provide more regional flavor. Provide an interoperable extensibility mechanism for a document author or application to specify their own art border graphics.  
DE Part 4, Section 2.18.86 and 2.18.57 - te The description of this type says it contains two hexadecimal digits, two hexadecimal octets and exactly two characters.  These definitions are not compatible.  A hexadecimal octet is two hexadecimal digits. Clarify the definition.  In particular note that xsd:hexBinary measure length in octets, not characters.  
DE Part 4, Section 2.18.45, 2.18.72, 5.1.12.37, 3.18.86, 3.18.87, 5.1.12.28 Line 10 ff, Line 10 ff, Line 10 ff, Line 2 ff, Line 2 ff, Line 10 ff ed Length is said to be “exactly 3 characters”, “exactly 10 characters”, “exactly 1 character”, “exactly 4 characters”, “exactly 3 characters”, ...  This is inconsistent with the examples given

The error in the text is that it confusing hex characters for hex octets.  It is never correct to say "This simple type's contents must have a length of exactly 2 characters" when 2 octets are intended.  These are not the same.  We must submit a comment to ensure that this is fixed,

Clarify the definition.  In particular note that xsd:hexBinary measure length in octets, not characters.  
DE Part 4, Section 2.18.72 and 5.1.12.37 - ed No definition is provided for a “Panose-1 classification” of a font. Provide a proper external normative reference for this term.

Here is missing reference to http://www.w3.org/Printing/stevahn.html

DIS  29500 should provide a list of normative references as expected

 
DE Part 4, Section 5.1.12.37   te The Panose value is said to be used, “so that generating applications using this Office Open XML  Standard may determine the closest font type if necessary”.  However, no font distance metric or font matching heuristic is described. Clause 2.18.72 in Part 4 is defining the ST_Panose type which is used by the panose-1 element specified in Clause 2.8.2.13. Actually it is there (2.8.2.13) where PANOSE Classification Guide, Version 1.2 is referenced. The reviewer references Part 4, Clause 5.1.12.37 where another ST_Panose type is defined which is used by the panose attributes  in Clauses 5.1.5.4.6, 5.1.5.3.1, 5.1.5.3.3, 4.3.1.10, 5.1.5.3.7, and 5.1.5.3.10 of Part 4.

DIS  29500 should provide a list of normative references as expected

 
DE Part 4, Section 2.18.85   te The fill patterns lack definitions.  The illustrations given are insufficient.  An application needs to know what in these illustrations are required behaviors and what are not.  For example, is the exact dithering pattern used in the illustration required?  Provide full normative definitions for these graphical elements.

The enumeration values are all specified in the following style: " Specifies that the pattern used for the current shaded region shall be a <...> pattern, as follows:" where <…> is replaced with current enumeration value. This would be no specification at all, if it were not for the graphics following the colon. These graphics are nevertheless underspecified and in some cases not really distinguishable from each other. We want to make clear that from our point of view elements of the standard must be specified in a way that allows a proper reproduction by any conforming consumer.

 
DE Part 4, Section 2.15.2.32 - te This feature has been defined in a way which ignores the existence of current browsers other than Internet Explorer.  What about Firefox?  What about Safari?  What about Opera? None of these can be set as target browsers.  This section requires that “all settings which are not compatible with the target web browser shall be disabled.”  But what if I want my application to produce standards-compliant output?  So yes to PNG, no to VML, yes to MathML and SVG?   I can't seem to specify this. Here is it better to write how the optimizing working on other browser like Firefox, Safari without deferentiating on version level.

Interoperability shall be tested with further browser and describe the setting.

 
DE Part 4, Section 2.8.2.16, 2.3.1.8, 2.4.7, 2.4.8, 2.4.51, 2.4.52, 2.15.1.87, 6.1.2.7 - te These elements uses a set of bitmasks to specify which code pages a given font supports.  The use of bitmasks rather than an XML Schema derived type makes this data almost impossible  to work with standard XML tools like XSLT which lack bit-level operations.  One of the advantages of XML is that we don't need to encode data like this any more. 

Part 4, 6.1.2.7, page 4444, “tableproperties” (see above!)

Rewrite this subclause to express the feature using XML constructs rather than bitmasks.  
DE Part 4, Section 2.16.5.33 - te This subclause defines an INCLUDEPICTURE field which “Retrieves the picture contained in the document named”.  However, no mention is made of what formats are permissible for the picture.  Add the following description to the spec: 
INCLUDEPICTURE is used to retrieve a picture from a file. Some of the formats of pictures that it supports are defined in section 5.2.13
 
DE Part 4, Section 2.16.5.33 - te This does not define how a picture is named.  Is it by a URI?  By a local file system path?  Either?    The example given has a DOS file path, a construct which is not portable. Add the following description to the spec:  
Section 2.16.6.33 is just an example. We can retrieve the picture contained in the document named by field-argument. We can use name or URL.
 
DE Part 4, Section 2.16.5.33 - ed This field says that it merely retrieves the picture contained in the named document.  Is nothing else to be done with the picture?  For example, should it be displayed? Add the following description to the spec:

This field is used to retrieve picture. After retrieving the picture, manipulations on that can be done using the picture property defined in the specification.   Example: "If you double-click a graphic inserted by the INCLUDEPICTURE field, Word displays the Format Picture dialog box. To change the graphic without using the drawing tools in Word, edit the graphic in the application it was created in, and then update the field in Word. "

 
DE Part 4, Section 2.16.5.34 - ed This subclause defines an INCLUDETEXT field which “Inserts all or part of the text and graphics contained in the document named”.  However, no mention is made of what formats are permissible for the retrieved text. Add the following description to the spec:

INCLUDE TEXT includes text from an external document into the existing document, the inclusion of text being similar to import of an alternative format into the current document. Therefore the various document formats from, which text can be included are mentioned in Section 11.3.1, Page 28. The different formats of documents supported are   • Text = application/txt• RTF = application/rtf• HTML = application/html• XML = application/xml  Text from another Word Processing document can also be included, as stated in the description of INCLUDE TEXT, Section 2.16.5.34, Page 1538, Line 1,2 and 3, which is,   "If the document is a WordprocessingML document, the portion marked by the optional bookmark field-argument-2 is inserted."   

 
DE Part 4, Section 2.16.5.34   ed The \t flag will apply a named XSLT transform to the input XML file and insert the resulting output.  However, no proper reference is given to XSLT, so we do not know what version XSLT transform is permitted here. XSLT version is not defined with "\t" switch, actually file of type xsl is defined. The file of type xsl will contain the XSLT version. So it is application defined.

But what versions of XSLT should an application compliant with OOXML expect to deal with?  For example, does MS Office handle the latest XSLT?  If not, we should specify what versions are allowed in order to improve interoperability.

DIS  29500 should provide a list of normative references as expected , add the expected reference!

 
DE Part 4, Section 2.16.5.34 - te This does not define how a document  is named.  Is it by a URI?  By a local file system path?  Either?  The example given has a DOS file path, a construct which is not portable. Pls specify: What are the allowed ways of "naming" an image.  In otherwords, what is the file name schema?  URI?  Local file system paths? Either?  Something else?  
DE Part 4, Section 2.3.3.19 - te This says that “The layout properties of this embedded object are specified using the VML syntax”.  However, in Part 1, Section 8.2.6 says, “VML should be considered a deprecated format included in Office Open XML for legacy reasons only and new applications that need a file format for drawings are strongly encouraged to use preferentially DrawingML”   Certainly a new document creating an OLE embedding should not be using VML.  Otherwise, all OOXML consumers will need to support VML, even where legacy documents are not present. Define layout properties of embedded objects using DrawingML rather than VML

VML remains in the standard for compatibility reasons. However, new software shall not use VML.  VML shall be used only for backward compatibility reasons to enable the migration of older documents to Open XML. One possibility would be to move VML to a separate section as an informative annex  or save as part

 
DE Part 4, Section 5.1.3.4 - ed This describes the attachment of a QuickTime video to a presentation object.  No description of the QuickTime format is provided.  Without specifying a version and supported codecs, there will be no interoperability. Describing the QuickTime format is out of scope for the OOXML specification as QuickTime is widely used file format.

A proper external reference must be provided.  By including an element that represents a QuickTime attachment, OOXML explictly has made this within scope of the standard.

 
DE Part 4, Section 6.1.2.19 pg. 4653 “equationxml” te This describes  the "equationxml" attribute of "shape" elements, "used to rehydrate an equation using the Office Open XML Math syntax". However, the "actual format of the contents of this attribute are application-defined", which makes them impossible to exchange between applications.  If we're going to have  a new math markup language in XML, and ignore the existing MathML,  let's at least use the new markup in its elemental form, as well-formed XML (not stuffed into an attribute value), and without extending it in application-dependent ways. Define equations in an interoperable way.  
DE Part 4, Section 6.1.2.19 pg. 4655, “gfxdata” te Describes a "gfxdata" attribute for the "shape" elements, which "contains DrawingML content" that is "base-64 encoded".  However, the "contents of this package are application-defined", so even though they "shall use the Parts defined by this Standard whenever possible" there is not sufficient information for an independent implementation to read this data or display the "DrawingML content" contained therein.  If we're going to have  a new graphics markup language in XML, and ignore the existing SVG,  let's at least use the new markup in its elemental form, as well-formed XML (not stuffed into an attribute value), and without extending it in application-dependent ways. Define this in an interoperable way.  
DE Part 4, Section 2.16.5.77 - te The example that illustrates USERINITIALS section instead shows  USERNAME. Correct the example..  
DE Part 4, Section 2 - ed It is desired to have improved interoperability between ODF and OOXML.  However, OOXML lacks the following feature:  Text blinking, Table cell protection, an option to specify "Numbers of lines" for widow or orphans lines,  'Manual' and 'From left' alignment in tables, Last line alignment in justified paragraph (provision that we can change the last line of the paragraph as Left, Center and Justify), allow 8192 table columns rather than OOXML's 63, ... We suggest it would be nice to have some description of ODF/Open XML Interoperability concerning some selected features shown in an informative section of the spec.  
DE Part 4 Section 2 2.18.91 ST_TabJc (Custom Tab Stop 
Type),
te "Many features have already been labelled as "deprecated" in ECMA-376…."  "a newly created standard (should) establish clear guidelines and not create any uncertainties through the use of vague descriptions…" For example, "eventually replacing any uses of VML in the Office Open XML formats...." VML remains in the standard for compatibility reasons. However, new software shall not use VML.  VML shall be used only for backward compatibility reasons to enable the migration of older documents to Open XML. One possibility would be to move VML to a separate section as an informative annex  or save as part  
DE Part4 Section 6 6.1 VML te "Many features have already been labelled as "deprecated" in ECMA-376…."  "a newly created standard (should) establish clear guidelines and not create any uncertainties through the use of vague descriptions…" For example, "eventually replacing any uses of VML in the Office Open XML formats...." VML remains in the standard for compatibility reasons. However, new software shall not use VML.  VML shall be used only for backward compatibility reasons to enable the migration of older documents to Open XML. One possibility would be to move VML to a separate section as an informative annex  or save as part  
DE Part 1, Clause 15.2.9, Part 3, Clauses 8.2.3, 8.2.4, 8.2.5   te "In its current form the components in DIS 29500 which are seen as the norm are not recognisable enough, which could lead to misunderstandings and vagueness when it comes to meeting the requirements needed to implement these standards." 
Example: "Embedded OLE Objects“
"In order for DIS 29500 to gain acceptance, the document's informative elements should branch out, and thereby separate from the actual normative contents."  
DE Part 1, Clause 2 & Clause 11.3.1, 2.18.4   ge "An unequivocal examination of the conformance of the standards would be impeded by the current specifications." As some parts are unspecified.

To some degree "...the specification is, in contrast, too detailed." "Often an element's attributes consist of itemised lists of a very specific value.  A particularly clear example is the "ST_Border" itemised list defined in WordprocessingML.

In order for DIS 29500 to gain acceptance, an adaptation of the level of detail used for the individual specification elements must occur.  
DE     ge There is "...considerable overlap between ISO/IEC 26300 and ECMA-376 … [as] both standards cover the same user needs." Therefore we suggest:  
1. a list of functionalities where ISO/IEC 26300 is to short and 
2. an analyses of functionalities. that need to be developed for ISO/IEC 26300

That could be shown in an informative section

 
DE Part 1 line 2 ed DIS 29500 is a multi-part document, not a multi-part Standard, i.e., the individual parts of this Standard are not themselves standards.

Additonal Comment: DIS 29500 document is divided into 5 parts; each individual part defines specifications for a particular scope. These parts can be used individually or collectively, based on the different requirements. The terminology is correct: DIS 29500 is a multi-part Standard, and no claim is made that it is composed of multiple "Standards" in the JTC sense.  

Correct the terminology to correctly reflect the status of DIS 29500, if it's nessary.  
DE Part 1, Section 2.3 line 14 ed Are additional syntactic constraints only normative when the cannot be feasibly expressed in the schema language? Who judges this?  The use of the word “whenever” is ambiguous.  Is this a condition under which such statements are normative or an explanation of why such statements exist?

Additional comment: The section 2.3: "What this standard specifies", line 14 specifies that if the schema language used in this standard cannot feasibly express all the syntactic constraints, then those constraints are provided in written form. Such expressions are normative. The application that implements this standard will judge if the additional syntactic constraints are normative or not. The editorial comment which explains why this statement is appropriate is useful to the reader and does not detract from the value of this statement.

What may be meant is that the additional syntactic constraints are normative, period.  Clarify this sentence, perhaps by omitting the editorial explanation about why such additional constraints are not in the schema.  
DE Part 1, Section 2.6 lines 33-34 ed Is this recommending that a non-public, internal-only, work-for-hire application author create “publicly available documentation” on what subset of the standard it supports? The business relationship between the software author and his customer should not be a concern of this standard. Change to read, “a software application should be accompanied by  documentation...”  
DE Part 1, Section 2.3 and 2.6 line 16 ed The use of the word “element” is ambiguous.  Is this to mean XML elements (but not attributes, character content, etc.)?  Or does this mean an element of the Standard, in the usage of ISO Directives, Part 2?

Additonal Comment: As the section 2.3 is referring to syntax and semantics of XML schemas, the scope of confusion is very less and  “element” here implicitly refer to the XML element.  

Clarify the use of the word “element” perhaps by saying “XML element” if  that is what is meant.  
DE Part 1, Section 4 behavior, unspecified

Office Open XML Document

ed This definition doesn't work, since the Standard, in defining compliance in Section 2, says that “compliance is purely syntactic”.  So no behaviors are required.  Therefore, by this definition, all behaviors are unspecified?  Surely this is not what is meant.

Are these two different definitions? Or two clause of which either will define the term?  Or both together define the term?

Clarify this definition.  Perhaps it is meant to say, “Behavior for which this Standard does not make a recommendation”?  
DE Part 1, Section 9.1.7 line 10 ed The naming convention giving is incorrect.  H is a hexadecimal digit, not a hexadecimal value. Follow correct usage pattern as established earlier in 9.1.1.  
DE Part 1, Section 9.1.9 line 25 ed Incorrect subject.  A producer qua producer does not round trip.

Additional Comment: However, assuming it is meant “A producer does not round trip”:   Producers need not necessarily be consumers. The sentence only means that the producers must take care that the unknown relationship, targeting an unknown part is preserved in case if a consumer is a producer as well. This doesn't mean that the consumer has to be a producer always.

Should say, “Conforming producers that are also consumers should...”  
DE Part 1, Section 9.2 page 18, line 8 ed Extra period following “explicit.”

Additonal Comment:

This is just a typographic error that can be corrected on preparation of a final Specification document.

Remove extraneous punctuation  
DE Part 1, Section 15.2.8   ed The examples given are rendered useless by the predominance of the VML in the markup.

Additional comment: Examples given through the standard will include more than just the specific element or elements being defined. This is the reason for using an example, so that one can see how the element would be used in a typical document.

Make a more succinct and clear example by concentrating on the control persistence.  
DE Part 2, Section 1. Scope page 1, lines 9 ed The 'well-defined naming guidelines' expression is an oxymoron in the context of a standard. This is reinforced in the case of OOXML proposal by the fact that 'guidance' parts of the text are explicitly meant to be informative only (as opposed to normative). Replace 'guidelines' with 'rules'.  
DE Part 4, Foreword page vi, line 9 ed Explicitly references annexes that are not provided in a humanly-readable format, whereas a human-readable format is required by JTC1 Directives 8.3.5 and Annex H 
this includes OpenPackagingConventions-RELAXNG.zip, OpenPackagingConventions-XMLSchema.zip, OfficeOpenXML-DrawingMLGeometries.zip, OfficeOpenXML-RELAXNG.zip, OfficeOpenXML-SpreadsheetMLStyles.zip, OfficeOpenXML-XMLSchema.zip.
Annexes should be provided in a humanly readable, lined-numbered format so it can be referenced and cited.  The reference to electronic form only annexes should be removed. 

Clarify the status of this annex

 
DE Part 4, Section 1. Part Overview page 1 ed The use of 'Part' for different things is confusing. Line 1 (title) it refers to Part 4 as a subpart of OOXML. Line 3 it implicitly refers to WordprocessingML, SpreadsheetML, etc. Use another word like 'subpart' when referencing WordprocessingML etc., or else use their full names.  
DE Part 4, Section 1.1 page 1, line 5 ed Table row 'Alternative Format Import' is deemed to have no root element and no reference. The value of this row is unclear. Clarify the table purpose.  
DE Part 4, Section 1.2 page 1, line 6 ed Table row 'Custom Property' is deemed to have no root element and no reference. The value of this row is unclear.

Additional comment: The custom property part exists to allow users to embed their own parts. As the part is defined by the user, and not the specification, it is not possible to document the root element.

Clarify the table purpose.  
DE Part 4, Section 1.5 page 3, line 1 ed Eleven table rows are deemed to have no root element and no reference. The value of these rows is unclear.

Additional Comment:

The eleven rows in question represent part types that do not have a defined root element. That is clearly shown in the specification.

Clarify the table purpose.  
DE Part 4, Section 2.2.1 page 27, lines 8-22

page 28

page 28 line 1

ed This example is unduly heavy, the image brings no value.

Additional Comment: The example specified in the  section 2.2.1 is the snippet to get the image shown. So there is a necessity for the referred image in the section 2.2.1 for clear understanding of the section.

The line numbering does not cope well with tables. In this particular case, the closest line number for the table of child elements lies on the previous page.   

The use of 'presented' in the 'This color may either be presented as a hex value (in RRGGBB format)' sentence is not appropriate, since the text is referring to the definition of the document contents, not its presentation.

Remove the image.

Number tables appropriately.

Use 'defined' or 'specified' instead.

 
DE Part4, Section 6.1 page 4343, lines 4&5 ed What does 'This namespace' refer to? There is no obvious namespace in the context of that sentence.

Additional comment: Since the entire section 6.1 in Part 4 is referring to the VML, “this name space” implicitly refers to the VML namespace.

Clarify.  
DE Part4, Section 6.1 page 4343, line 5 ed The relationship of 'Other VML namespaces' to the OOXML proposal is unclear. If the said other namespaces are related to OOXML, clarify the relationship, else remove the reference to them from the text.  
DE Part4, Section 6.1 page 4343, line 9 ed The reference to the specific commercial product 'Office 2000' brings no value to the proposal.

Additional Comment: This content is informative and is provided to give background into the history of VML. It is believed that this is actually useful information.

Remove the reference to Office 2000.  
DE Part 4, Section 2.3.3.14 page 256, line 4 ed This sentence makes no sense in English. Rewrite the sentence in English or remove it.  
DE Office Open XML Overview   ge This document is not listed as part of the Ecma 376 standard in the Forward to Part I “Fundamentals” and its status whether informative or normative is not explicitly stated.

Additional Comment: It is agreed that the Overview document is non-normative, however it is a useful paper to the implementer and consistent with similar information found in other standards. An appropriate disposition recommendation will be taken by Ecma as part of the response to this comment.

Clarify the status of this Overview document.  If it is merely a promotional whitepaper about Ecma 376, then it should not be included in the published standard.  
DE Part 1, Section 2.1, 2.2 “Goal”

“Issues”

ge There are no normative statements in this clause, though Section 2 is indicated to be normative

Additional Comment: Section 2.1 “Goal”, as well as Section 2.2 “Issues”describes the goal of this Section 2 and does not prescribe implementable behavior, and thus is not properly described as "normative" - but there should be no confusion in any implementer's reading as to whether this Section 2 is "normative" with respect to an implementation of the specification. There is no reason to make such a change.

Mark clause as informative using one of the mechanisms of Section 7  
DE Part 2   ge Part 2 defines Open Packaging Conventions (OPC) in terms that, according to Part 1, Section 9.1 Constraints on Office Open XML's Use of OPC, are more general than needed for the purpose of OOXML. This is due to bring confusion, and should be resolved. Part 2 should be amended either by: a) referencing an established standard (in which case placing documented constraints upon its use in OOXML would be fine), or else b) tightening Part 2 contents so as to keep it focused on OOXML related matters, or else c) submit OPC as a separate packaging-focused standard and, provided that it is accepted as a standard, apply option a) to it.  
DE Part 4   ge The OOXML text explicitly refuses to elaborate on some behavioral aspects of the conforming applications. For example, it refuses to cover the how and when fields are updated. In contradiction with this, many features cannot be defined without defining more precisely the very same behavioral aspects (for example, the ASK field). There is a tension here that leads us to consider that the text must either provide the appropriate definition of the behavioral context into which it frames behavioral aspects it proposes, or else, more in line with its announced scope, which is static in essence, the said behavioral aspects must be expunged from it. Define the behavioral context of compliant applications or remove all behavioral aspects from the OOXML text.  
DE Part 4, Section 5.1.12.37   ge Why are there several different definitions for a Panose value, both in Word Processing ML as well as Drawing ML?  Since they are exactly the same they should be defined once in a shared schema.  
DE     ge From the beginning, office suite applications by Microsoft were benefiting from their proprietary standards, where other parties were unable to implement such standard and make their products compatible. Microsoft decided to ignore the existing open standards, and as we have seen in the past, they are trying to bring upon a new "open" proprietary standard that can be fully integrated only by Microsoft itself. There have been Open Standards for document exchange out there for a longer time, Microsoft had pledged only one step for its implementation, but in the end it turns out to be a third party plug-in which was made by another developer (Sun Microsystems).

No standard can be backwards compatible; this is an application feature, which can support different versions of one standard.

Additional Comment: Novell, OpenOffice.org, Corel and Microsoft  have already announced support for Open XML Formats in their products. Novell and Microsoft have already introduced support, OpenOffice.org and Corel will provide Open XML support later this year. Assertions that only Microsoft is capable of supporting the Open XML formats are clearly false.

   
DE     ge To date, the standard has not been implemented by its vendor or the competition. It is clear that the Microsoft product will switch to their "open" standard in a certain time; does this mean competition in the field of standards?    
DE     ge More than 10% of the examples shown in the spezification are not proper XML 
Additonal Comment: See for example, this study by a BSI member:  http://surguy.net/articles/ooxml-validation-and-technical-review.xml
An Review of the listed examples should clarify if there are XML-valid or XML-invalid examples shown  
DE Part 1, section 2.5   ed Given the scope, breadth and depth of the specification, including the numerous passages marked as “informative” only, the conformance criteria here seem few and vague. Specify exact conformance criteria, possibly for different levels (minimal, full etc.) and/or for specific subsets of the specification and/or from the perspective of different categories of implementing software (visual editors, renderers, batch filters, pass-through systems etc.)

f.e.g. Profiling could be a proper solution

 
DE Part 1, section 9.1.9 Line 25f ed "Are encouraged to…" is too imprecise. The ability to round-trip application-defined (ie, "unknown" from the perspective of the specification) relations is essential for reliable business process integration. Specify explicit conformance criteria for round-tripping application-defined relations.  
DE Part 1, section 11.3.1   ed Arbitrary (in quality and quantity) alternative format content essentially undermines the effort of interoperable documents. It would be possible to re-package with minimal effort a legacy format document into a document which would be technically conformant to the present specification but would also be essentially useless for a consumer that is not aware of the legacy format. Restrict the use of alternative format imports (eg, requiring a  parallel import of a format conforming to this specification, somewhat like MIME's multipart/alternative) and/or specify an explicit conformance level for customers to choose which would require producers to not only "black-box" legacy format content.  
DE Part 1, section 11.9 XSL Line 13 ed "… an XSL Transformation which might be applied on save …" is too imprecise both wrt. conformance criteria and the function in principle. Specify what data the XSL transformation operates on, when it is applied and where the result is stored. Also specify conformance criteria if support for this operation is not mandatory.  
DE Part 1, section 15.2.1    ed It is unclear how this part of the specification, wrt. its intended use or its function, relates to other parts of the specification that also allow application-defined data to be embedded into a document (Custom XML Data Storage, Custom XML Data Storage Properties, Smart Tags, Custom Markup, Structured Document Tags). It is also unclear how producer characteristics should be handled in a processing chain of linked producers and consumers. State intended use, relation to other parts and conformance criteria wrt. producer-chains more precisely.  
DE Part 1, section 15.2.14    ed This is highly system-specific and not implementable in a vendor-independent way. Consider a server-side workflow application preparing a report document for a user that is intended to go to a specific printer and use a specific type of pre-printed form. Specify an application-extensible base set of printer settings in a vendor-neutral XML representation.  
DE Part 2, section 8.1.1 Page 12, line 11 ed The notation "[M1.1]" has not been introduced before its first use here and becomes only clear in Annex H. Introduce clause notation.  
DE Part 2, section :8.3.5 Page 21, line 35f te "Producers editing relationships based on this version of the relationship markup specification shall not preserve any ignored content..." Explicitly required non-roundtrip behavior would break business process integration with application-defined data. Require round-trip behavior.  
DE Part 2, section 9.2.5 Line 26f ed The semicolon does not have a special meaning on Unix file systems. (It does, however, have a special meaning in typical Unix command-interpreters ["shells"], which is insignificant for this specification). Delete list item.  
DE Part 2, section 9.1.3.1 Page 29, line 3f ed Logical part names may include %-escaped sequences. The specification presumably intends that a logical name of “%C3%B1.ext” will result in a Zip item name of “%C3%B1.ext”, not  “ñ.ext” (interpreted as 2-byte UTF-8 sequence). This becomes clear only later. Specify comparison and equality rules more precisely.  
DE Part 2, section :A.4    ed The term "Unicode string" is unspecified and, from what the term suggests, the examples are confusing. A "Unicode string" is presumably a string of Unicode characters, possibly with "/" characters and therefore intended to be interpreted as a file system path. It is, however not logical, to assume a Unicode string is already %-escaped (otherwise, "Unicode string" and "IRI" would be identical concepts). Consider, eg, the string "/test/50%_chance.xml". Thus, an original Unicode string of “/%41/%61.xml” (a sequence of the Unicode characters “/”, “%”, “4”, “1”, “/” …) must be represented as an IRI or URI “/%2541/%2561.xml”. Also if a Unicode string is intended to be interpreteted as a unified file system path with national characters, a backslash "\" character in the original string should be mapped to a "/" character in the IRI, and not %-escaped. Verify the intended encoding rules and examples and specify the term "Unicode string".  
DE Part 2 section A Page 64, line 3f ed "Values of xsd:anyURI data type within XML markup are Unicode strings." is an error. Values of xsd:anyURI are, as the XML Schema specification states, URIs. Such a value may be represented as an *ASCII* string within an application. It does not seem useful to introduce an unclear term "Unicode string" here. Verify term an intended interpretation.  
DE Part 1, section 2.5 line 30 ed specifies that "A conforming producer shall be able to produce conforming documents". This is unclear insofar as that it permits the existence of "conforming producers" capable of producing 
- two simple, conformant "Hello World"-documents 
- other, non-conformant documents. 
Such an application still would be a "conforming producer", since it is "able to produce conforming documents".
rephrase to read "all Office OpenXML documents produced by a conforming producer shall be conforming documents."  
DE Part 1, section 11.3.1    ed "Alternative Format Import Part" (AIP), is unclear. Suggestion: Clarify the text by introducing a clear separation of applications filling the roles of 
- "consumer only" 
- "consumer + producer" 
- "producer only". 
Specify the functionality that each role must support: 
- "consumer only" must not reject documents containing AIP 
- "consumer + producer" must convert data in AIP before acting as producer 
- "producer only" is the only role allowed to produce OpenXML documents containing AIP
 
DE Part 4, Section 2.16.5.71 page 1565, line 4 ed The 'Retrieves' verb explicitly references a runtime behavior, which is out of the documented scope of the OOXML proposition, and not operable as far as a document storage format is concerned. The resulting definition for 'TEMPLATE' is broken. Instead of using 'Retrieve' verb it would be better to use 'return'.  

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 39

ISO electronic balloting commenting template/version 2001-10


Top