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

CL Part 1, introduction and many clauses in the rest of the standard   ge Introduction explicitly says that OOXML objective is to be "fully compatible with the large existing investments in Microsoft Office documents". Standards should not be built to be compatible with an existing software; it's exaclty the other way. As there exists an ISO standard for documents, spreadsheets and presentations (ISO 26300, Open Document Format), which is the objective of OOXML, this standard should be rejected in favor of ISO 26300.  
CL Part 4, section 2.15.3.6 Element 'autoSpaceLikeWord95' ge This paragraph defines an element whose only objective is to be compatible with an old obsolete commercial software.

Standard says: "to faithfully replicate this behaviour, applications must imitate the behaviour of that application, which involves many possible behaviours and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behaviour, they must utilize and duplicate the output of those applications.".

Despite it states also that this issue is deprecated and that applications should not replicate this behaviour, it is not convenient for an standard to have an element that describes its behaviour in terms of the output of a commercial closed software.

To include a complete description of the behaviour or to eliminate the entire paragraph.  
CL Part 4, section 2.15.3.64 Element 'useWord97LineBreakRules' ge This paragraph defines an element whose only objective is to be compatible with an old obsolete commercial software.

Standard says: "to faithfully replicate this behaviour, applications must imitate the behaviour of that application, which involves many possible behaviours and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behaviour, they must utilize and duplicate the output of those applications.".

Despite it states also that this issue is deprecated and that applications should not replicate this behaviour, it is not convenient for an standard to have an element that describes its behaviour in terms of the output of a commercial closed software.

To include a complete description of the behaviour or to eliminate the entire paragraph.  
CL Part 4, section 2.15.3.63 Element 'useWord2002TableStyleRules' ge This paragraph defines an element whose only objective is to be compatible with an old obsolete commercial software.

Standard says: "to faithfully replicate this behaviour, applications must imitate the behaviour of that application, which involves many possible behaviours and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behaviour, they must utilize and duplicate the output of those applications.".

Despite it states also that this issue is deprecated and that applications should not replicate this behaviour, it is not convenient for an standard to have an element that describes its behaviour in terms of the output of a commercial closed software.

To include a complete description of the behaviour or to eliminate the entire paragraph.  
CL Part 4, section 2.18.66 Table with styles, style "chicago" ge Description of style "chicago" includes a "Chicago Manual of Style", without any reference. To include a complete reference for the manual, or to eliminate the style.  
CL Part 4, section 2.18.66 Table with styles, style "ideographDigital" ge Description of style is ambiguous: it does not clarify what is an "appropiate character", and what "sequential numerical ideographs" means. To clarify ambiguity or to eliminate the style.  
CL Part 4, section 2.18.66 Table with styles, style "ideographEnclosedCircle" ge Description of style is ambiguous: it does not clarify what is an "appropiate character", and what "sequential numerical ideographs" means. To clarify ambiguity or to eliminate the style.  
 
 
 
 
CL Part 4, section 6.1.2.19 In table of attributes and their descriptions te Most attributes are contained in Microsoft XML namespaces. A standard must not contain references to namespaces contained and described in private URIs. To replace namespaces URIs by URIs not owned by Microsoft.  
CL Part 4, section 6.1.2.19 In table of atributes and their descriptions, attribute 'gfxdata' te This attribute contains a base-64 representation of a VML object. VML is an obsolete commercial standard, and the possibility to include VML objects should be avoided. To eliminate the attribute and their references.  
CL Part 4, section 2.18.51 Element 'ST_Lang' te Element 'ST_Lang' is defined as a union of two incompatible descriptions of languages: ISO 639 language codes, and a list of prefixed language codes, duplicating definitions. This should be avoided. To redefine element referencing just one source with ISO language codes, as ISO 639, ISO 3166 or a coherent combination of both.  
CL Part 4, section 2.18.51 Element 'ST_LangCode' te Element 'ST_LangCode' describes a list of prefixed language codes that contradicts and duplicates ISO 639 language codes. This should not be accepted in an ISO Standard. To eliminate the element and their references.  
CL Part 3, section 3.16.9.1

Part 4, section 3.17.4.1

'Date representation' te OOXML has two different bases for date representation. This is unjustified, and should be avoided, as it shall produce unnecesary confusion in implementation. To integrate bases and keep just one of them, flexible enough to allow actually used date values.  
CL Part 3, section 3.16.9.1

Part 4, section 3.17.4.1

'Date representation' te First one allows dates between 1900 and 9999 – and no before. This is insufficient for many purposes (historical calculations, there still are alive people born before 1900, etc.).

Second proposed representation allows dates between 1904 and 9999– and no before.

To replace proposed date range type for a range compatible with ISO 8601, allowing dates previous to 1900.  
 
 
 
 
 
CL Part 3, section 3.16.9.1

Part 4, section 3.17.4.1

'Date representation', first date base. te First base described for date representation replicates an old problem of MS Excel systems, considering 1900 as a leap year. This is done just for back compatibility with MS Excel, and introduces complex and unuseful date transformations when implementing this feature.

It is also against an accepted ISO standard (ISO 8601).

Both previous facts are unacceptable in an ISO standard.

To replace proposed date representation with another that conforms to ISO 8601.  
CL Part 4, section 3.17.7.341 'Weekday' function te This function calculates week day according to 1900 leap year bug, described in observations to Part 3, section 3.16.9.1 and Part 4, section 3.17.4.1. A software error should be corrected, not documented in a standard. To adequate function description to a date representation that conforms to ISO 8601.  
CL Part 4, sections 2.4.51 and 2.4.52 Element 'tblLook' te These paragraphs describes 'bitmasks' to be applied to obtain representation of tables. This is not acceptable, as XML does not include tools or specifications to handle this kind of data, for example in XSLT standard. To adequate this specification to XML specification, eliminating references to bitmasks.  
CL Part 4, section 3.17.7.287 Sin() function te Specification for this function does not specify wheter angle arguments are expressed as radians or degrees. To specify if argument should be expressed as radians or degrees..  
CL Part 4, section 3.17.7.50 Cos() function te Specification for this function does not specify wheter angle arguments are expressed as radians or degrees. To specify if argument should be expressed as radians or degrees..  
CL Part 4, section 3.17.7.313 Tan() function te Specification for this function does not specify wheter angle arguments are expressed as radians or degrees. To specify if argument should be expressed as radians or degrees..  
 
 
 
CL Part 4, section 3.17.7.12 Asin() function te Specification for this function does not specify wheter angle arguments are expressed as radians or degrees. To specify if argument should be expressed as radians or degrees..  
CL Part 4, section 3.17.7.4 Acos() function te Specification for this function does not specify wheter angle arguments are expressed as radians or degrees. To specify if argument should be expressed as radians or degrees..  
CL Part 4, section 3.17.7.14 Atan() function te Specification for this function does not specify wheter angle arguments are expressed as radians or degrees. To specify if argument should be expressed as radians or degrees..  
CL Part 4, section 3.17.7.15 Atan2() function te Specification for this function does not specify wheter angle arguments are expressed as radians or degrees. To specify if argument should be expressed as radians or degrees..  
CL Part 4, section 3.17.7.17 Avedev() function te Function description and function math calculation for this function are incoherent. Equation describes number of combinations of N over K, and function description is about average deviation of a set of values. To correct this error.  
CL Part 1, section 8.6.2 Note about VML standard te Note included in this paragraph says explicitly that VML is an obsolete and deprecated standard introduced by Office 2000, and included just for legacy reasons.

Deprecated standards should not be accepted in a standard. Deprecated features should be avoided in standards, not included.

We propose to replace completely all references to VML in OOXML for an W3C accepted standard (SVG), or an ISO standard (ISO 8632).  
CL Part 4, section 7.2 'Math' specification te This specification conflicts with MathML specification, included in ISO 26300 for Open Document Format. As there exists an ISO standard for equation representation, we propose to replace completely 'Math' specification with the one included in ISO 26300.  
CL Part 4, section 2.15.1.28 'document protection' te This element describes a mandatory hashing algorithm to store a password to protect a document, that is explicitly described to be included 'for legacy reasons'. This hashing algorithm is different from widely known and used hashing algorithms, and is potentially a security hole for users pretending to protect private or secret information through this mecanism. To replace this hashing algorithm by one (or more) of following standards: ISO 10118-3, SHA-1, SHA-256, SHA-384, SHA-512, RIPEMD-160 or MD5.  
CL Part 4, section 3.3.1.69 Attribute 'password' te This attribute describes an algorithm to calculate a password to protect a range of cells in a spreadsheet. This hashing algorithm is different from widely known and used hashing algorithms, and is potentially a security hole for users pretending to protect private or secret information through this mecanism. To replace this hashing algorithm by one (or more) of following standards: ISO 10118-3, SHA-1, SHA-256, SHA-384, SHA-512, RIPEMD-160 or MD5.  
CL Part 4, section 4.6 'Animation' section ge This whole section describes animation specification for PresentationML, which according to proposed standard is 'loosely based on the syntax and concepts from SMIL, a W3C recommendation'. As there exists an standard for object animation (W3C SMIL), we propose to use this standard.  
CL Part 3, sections 5.7.2 and 5.9.2.1 EMU unit te These sections introduce a new measurement unit called EMU. In section 5.7.2 is defined as '914400 EMUs per inch', and in section 5.9.2.1 is defined as '91440 EMUs/U.S. Inch, 36000 EMUs/cm'. These two definitions are different and incoherent. Moreover, this unit of measurement is not documented anywhere in existing literature. Many elements and objects in Part 4 of the standard are defined based on EMUs. To define consistently an EMU, or to replace EMU unit with a previously existing well documented unit.  
CL Part 4, section 2.18.51 Element 'ST_Lang' te Table describing language codes are described to fit in two hexadecimal digits, but it actually needs four. To replace the expression "two hexadecimal numbers" by "four hexadecimal numbers", and to replace decimal number list with an hexadecimal number list.  
CL Part 4, section 2.16.4 Section 'Field formatting' te This whole section describes a set of marks and special characters designed to format field contents. This is incompatible with XML and is a serious conflict with XML main purpose. As our country has fixed XML as its mandatory information interchange standard through supreme decree 81/2004, this is against out national norms. To delete all references to special characters and redesign them to conform to XML.  
  OfficeOpenXML-DrawingMLGeometries.zip

OfficeOpenXML-RELAXNG.zip

  ge This annex was not provided in a format permitted by JTC1 Directives 8.3.5 and Annex H. A ZIP file filled with XML documents is not a permitted format for submitting a DIS.

This annex was not provided in a format permitted by JTC1 Directives 8.3.5 and Annex H. A ZIP file filled with XML documents is not a permitted format for submitting a DIS.

The provisions of JTC1 Directives 8.3.5 and Annex H must be complied with.

The provisions of JTC1 Directives 8.3.5 and Annex H must be complied with.

 
  OfficeOpenXML-SpreadsheetMLStyles.zip   ge This annex was not provided in a format permitted by JTC1 Directives 8.3.5 and Annex H. A ZIP file filled with XML documents is not a permitted format for submitting a DIS. The provisions of JTC1 Directives 8.3.5 and Annex H must be complied with.  
  OfficeOpenXML-XMLSchema.zip   ge This annex was not provided in a format permitted by JTC1 Directives 8.3.5 and Annex H. A ZIP file filled with XML documents is not a permitted format for submitting a DIS The provisions of JTC1 Directives 8.3.5 and Annex H must be complied with.  
  OpenPackagingConventions-RELAXNG.zip   ge This annex was not provided in a format permitted by JTC1 Directives 8.3.5 and Annex H. A ZIP file filled with XML documents is not a permitted format for submitting a DIS. The provisions of JTC1 Directives 8.3.5 and Annex H must be complied with.  
  OpenPackagingConventions-XMLSchema.zip   ge This annex was not provided in a format permitted by JTC1 Directives 8.3.5 and Annex H. A ZIP file filled with XML documents is not a permitted format for submitting a DIS. The provisions of JTC1 Directives 8.3.5 and Annex H must be complied with.  
  Part 1, Annex A   te The reference given for the Zip format does not provide a date or version, though this specification is frequently Reference should be made to a particular dated and labeled version.  
  Part 1, Forward 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, the individual "parts" do not today have individual conformance clauses, etc. Correct the terminology to correctly reflect the status of DIS 29500.  
CL 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. This is a serious issue. That language of 11.3.1 specifies explicitly the formats required ("HTML, MHTML, RTF, earlier 4 versions of WordprocessingML, or plain text") as well as makes the normative statement, "A WordprocessingML consumer shall treat the contents of such legacy text files as if they were formatted using equivalent WordprocessingML, and if that consumer is also a WordprocessingML producer, it shall emit the legacy text in WordprocessingML format."
  Part 1, Section 11.9 XSL Transformation Line 13 ed "… an XSL Transformation which might be applied on save …" is too imprecise both wrt. conformance criteria and the function in principle. Consider that an OOXML document, a specified in this standard is comprised of multiple XML documents in a Zip container. A great detal more detail must be given to explain how an XSLT transform will operate in that context. 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.
  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. There is not even a single example of why or how this feature would be used. Considering the security risks of undefined binary blobs in a document, this features should be removed and vendors referred to the extensibility mechanisms of Part 5 for preferred extension mechanisms.
  Part 1, Section 15.2.12 - te 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 an external normative 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"
  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. The DEVMODE structure stores many common settings, such paper orientation, paper size, number of copies, print quality, etc. There is no reason why these settings should be application or printer-specific. They should be stored in format that all applications can gain access to. Alternatives are available for expressing print settings in XML rather than in binary. For example, Microsoft's own XPS specification defines a PrintTicket markup for which the XPS specifications says, “The PrintTicket is XML that provides print settings in a consistent, accessible, and extensible manner. We would like the same qualities in OOXML's print settings, not a binary blob.
  Part 1, Section 15.2.6 - te 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? Multiple incompatible interpretations are possible. Clarify the meaning.  
  Part 1, Section 11.9 XSL Transformation Line 13 ed "… an XSL Transformation which might be applied on save …" is too imprecise both wrt. conformance criteria and the function in principle. Consider that an OOXML document, a specified in this standard is comprised of multiple XML documents in a Zip container. A great detal more detail must be given to explain how an XSLT transform will operate in that context. 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.
  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. There is not even a single example of why or how this feature would be used. Considering the security risks of undefined binary blobs in a document, this features should be removed and vendors referred to the extensibility mechanisms of Part 5 for preferred extension mechanisms.
  Part 1, Section 15.2.12 - te 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 an external normative 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"
  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. The DEVMODE structure stores many common settings, such paper orientation, paper size, number of copies, print quality, etc. There is no reason why these settings should be application or printer-specific. They should be stored in format that all applications can gain access to. Alternatives are available for expressing print settings in XML rather than in binary. For example, Microsoft's own XPS specification defines a PrintTicket markup for which the XPS specifications says, “The PrintTicket is XML that provides print settings in a consistent, accessible, and extensible manner. We would like the same qualities in OOXML's print settings, not a binary blob.
  Part 1, Section 15.2.6 - te 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? Multiple incompatible interpretations are possible. Clarify the meaning.  
  Part 1, Section 11.9 XSL Transformation Line 13 ed "… an XSL Transformation which might be applied on save …" is too imprecise both wrt. conformance criteria and the function in principle. Consider that an OOXML document, a specified in this standard is comprised of multiple XML documents in a Zip container. A great detal more detail must be given to explain how an XSLT transform will operate in that context. 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.
  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. There is not even a single example of why or how this feature would be used. Considering the security risks of undefined binary blobs in a document, this features should be removed and vendors referred to the extensibility mechanisms of Part 5 for preferred extension mechanisms.
  Part 1, Section 15.2.12 - te 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 an external normative 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"
  Part 4   ge The OOXML text explicitly refuses to elaborate on 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.  
  Part 4, 3.3.1.69 page 2004 te The hash algorithm is being used neither secure nor is standardized. We are concerned is that no evidence has been given that algorithm has been peer-reviewed by security experts. Certainly it is a legacy algorithm, but a cursory search of Google for "word password crack" shows that there are very many tools that break it. Therefor it is desired that a secure, reviewed and standard algorthm be used, such as SHA-256 as the default algorithm. Make the default hash algorithm for this clause be SHA-256 as defined in ISO/IEC 10118-3:2004 "Dedicated hash-functions"  
  Part 4, Annex C. Additional Syntax Constraints page 5205, line 5&6 te The 'These additional constraints can be deduced from the normative content of this Part' proposition falls short of what is expected from a standard. Either the OOXML text defines the constraints and they can be read from it, or else the OOXML text does not define the constraints (and the reader has to 'deduce' them from the text, which would be unacceptable). Requring decuction is a good way to guarantee interoperability problems. The text of this section suggests 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. Note that the standard regularly confuses informative and normative content, with "shall" used in clauses labeled informative, and "must" incorrectly used in normative content. So requiring the reader to "deduce" what was intended is not acceptable. The standard must make conformance requirements clear and unambiguous.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely blinking text. Add support for blinking text.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely Table cell protection. Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely an option to specify "Numbers of lines" for widow or orphans lines Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely 'Manual' and 'From left' alignment in tables Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely: Last line alignment in justified paragraph (provision that we can change the last line of the paragraph as Left, Center and Justify) Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : allow 8192 table columns rather than OOXML's 63 limit Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely: 'Leading' line spacing in a paragraph Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely: Tabs fill character of a paragraph Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely 'Title' and 'lowercase' style options Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely: table can have 'keep with next paragraph' set Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : a 'May Break Between Rows' attribute so as not to split a table Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely: allow entire sections to be marked as hidden Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : Background Image in Tables -- background image can be defined for an entire table, a row or an individual cell. This image is automatically resized when modifying the table. Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : Contents in a multi-column section can be evenly distributed resulting in balanced columns Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : an option to rotate the text by 90 as well as 270 degrees. Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : any number of rows can be selected for repeating Heading Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : Copy Heading while splitting Table Include support for this feature from ISO ODF in order to improve interoperability between the two formats.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : Table Shadowing Style Include support for this feature from ISO ODF in order to improve interoperability between the two formats.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : vertical numbering in list items Include support for this feature from ISO ODF in order to improve interoperability between the two formats.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : image can be positioned absolutely within a frame Include support for this feature from ISO ODF in order to improve interoperability between the two formats.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely: Last line alignment in justified paragraph (provision that we can change the last line of the paragraph as Left, Center and Justify) Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : allow 8192 table columns rather than OOXML's 63 limit Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely: 'Leading' line spacing in a paragraph Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely: Tabs fill character of a paragraph Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely 'Title' and 'lowercase' style options Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely: table can have 'keep with next paragraph' set Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : a 'May Break Between Rows' attribute so as not to split a table Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely: allow entire sections to be marked as hidden Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : Background Image in Tables -- background image can be defined for an entire table, a row or an individual cell. This image is automatically resized when modifying the table. Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : Contents in a multi-column section can be evenly distributed resulting in balanced columns Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : an option to rotate the text by 90 as well as 270 degrees. Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : any number of rows can be selected for repeating Heading Include this feature in WordProcessingML in order to improve interoperability.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : Copy Heading while splitting Table Include support for this feature from ISO ODF in order to improve interoperability between the two formats.  
  Part 4, Section 2 - te OpenOffice is attempting to add support for OOXML. However OOXML lacks support for a feature of OpenOffice, namely : Table Shadowing Style Include support for this feature from ISO ODF in order to improve interoperability between the two formats.  
  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.

We need to keep in mind that the password may be entered by one machine (client) but then the hash calculated and stored by the server, which may be on a different machine architecture. Since we are doing bit-level manipulations, it is critical that byte order assumptions are made explicit. 

Also, something must be said about the character encoding that the string is in when processing begins. At that point we are dealing with character data at the application level. Nothing is in XML yet. So we need to be explicit about the assumptions. 

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

Although MS may believe that all documents can be divided into these three times, this is not true for all vendors who might use this standard. Ultimately, this is a business question, not a standards question, so the standard should be defined flexibly enough to adapt to business in this regard. So we reiterate the recommendation that this be defined as an xsd:string.

Loosen the type to an xsd:string to allow applications to provide their own document taxonomy.  
  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. Ecma should rethink the entire optimizeForBrowser subclause. It looks very much like it is mapping directly to the arbitrary choices of a single vendor's application. This clause should be rewritten to express this feature in an application and platform neutral way.  
  Part 4, Section 2.15.3 - te 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. Remove the compatibility settings from OOXML and have MS Office use the extensibility mechanisms of Part 5 of this standard to express this application-specific behaviors  
  Part 4, Section 2.15.3.26 page 1416, lines 14-17 te This is the “footnoteLayoutLikeWW8” element. The text given says, "This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 6.x/95/97) when determining the placement of the contents of footnotes relative to the page on which the footnote reference occurs. This emulation typically involves some and/or all of the footnote being inappropriately placed on the page following the footnote reference." 

Unsufficient detail is given for an application to replicate the desired behavior.

Define the intended behavior.

We appreciate that this element is intended for backwards compatibility and is optional. However, if a vendor does want to fully implement the standard, for example, in order to read and display all OOXML documents, then this definition is insufficient.

On the other hand, if we think that no other vendor will fully implement this specification, then this brings into question its suitability for an International Standard.

 
  Part 4, Section 2.15.3.31 - te This is the “lineWrapLikeWord6” element. The text given says "This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 6.0) when determining the whitespace compression of the final character on each line in the document. This emulation typically results in characters ending a line that may be compressed on the right being compressed on the right irrespective to whether the compression will allow another character to be included on the given line or not.

Unsufficient detail is given for an application to replicate the desired behavior. It is not enough to say what this emulation “typically results in”

Define the intended behavior.

We appreciate that this element is intended for backwards compatibility and is optional. However, if a vendor does want to fully implement the standard, for example, in order to read and display all OOXML documents, then this definition is insufficient.

On the other hand, if we think that no other vendor will fully implement this specification, then this brings into question its suitability for an International Standard.

 
  Part 4, Section 2.15.3.32 - te This is the “mwSmallCaps” element. The text given says, "This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 5.x for the Macintosh) when determining the resulting formatting when the smallCaps element (§2.3.2.31) is applied to runs of text within this WordprocessingML document. This emulation typically results in small caps which are smaller than typical small caps at most font sizes." 

Unsufficient detail is given for an application to replicate the desired behavior. It is not enough to say what this emulation "typically results in." Font sizes everywhere else in this standard are indicated with precision by point sizes or TWIPS. The same should be done here.

Define the intended behavior.

We appreciate that this element is intended for backwards compatibility and is optional. However, if a vendor does want to fully implement the standard, for example, in order to read and display all OOXML documents, then this definition is insufficient.

On the other hand, if we think that no other vendor will fully implement this specification, then this brings into question its suitability for an International Standard.

 
  Part 4, Section 2.15.3.41 page 1442, lines 13-18 te This is the “shapeLayoutLikeWW8” element which is defined as: "This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 97) when determining how to wrap text around floating objects using topAndBottom wrapping defined using the Vector Markup Language (VML) syntax. This emulation typically results in the wrapping above and below the object allowing the text to wrap more tightly around the object (text wraps more tightly around the object than it normally would)."

Unsufficient detail is given for an application to replicate the desired behavior. It is not enough to say what this emulation "typically results in" or vague terms like "more tighly than normal."

Define the intended behavior.

We appreciate that this element is intended for backwards compatibility and is optional. However, if a vendor does want to fully implement the standard, for example, in order to read and display all OOXML documents, then this definition is insufficient.

On the other hand, if we think that no other vendor will fully implement this specification, then this brings into question its suitability for an International Standard.

 
  Part 4, Section 2.15.3.51 page 1462, lines 11-16 te This is the “suppressTopSpacingWP” element. The definition given is, "This element specifies that applications shall emulate the behavior of a previously existing word processing application (WordPerfect 5.x) when determining the resulting spacing between lines in a paragraph using the spacing element (§2.3.1.33). This emulation typically results in line spacing which is reduced from its normal size."

Unsufficient detail is given for an application to replicate the desired behavior. It is not enough to say what this emulation "typically results in" or vague terms like "reduced from its normal size."

Define the intended behavior.

We appreciate that this element is intended for backwards compatibility and is optional. However, if a vendor does want to fully implement the standard, for example, in order to read and display all OOXML documents, then this definition is insufficient.

On the other hand, if we think that no other vendor will fully implement this specification, then this brings into question its suitability for an International Standard.

 
  Part 4, Section 2.15.3.53 page 1467, lines 9-14 te This is the “truncateFontHeightsLikeWP6” element, which is defined in these terms: "This element specifies that applications shall emulate the behavior of a previously existing word processing application (WordPerfect 6.x) when determining the character height for characters in a font. This emulation typically results slightly truncated character heights." 

Unsufficient detail is given for an application to replicate the desired behavior. It is not enough to say what this emulation "typically results in" or vague terms like "slightly truncated."

Define the intended behavior.

We appreciate that this element is intended for backwards compatibility and is optional. However, if a vendor does want to fully implement the standard, for example, in order to read and display all OOXML documents, then this definition is insufficient.

On the other hand, if we think that no other vendor will fully implement this specification, then this brings into question its suitability for an International Standard.

 
  Part 4, Section 2.15.3.54 - te This is the “ uiCompat97To2003” element, which is defined as: “Disable UI functionality that is not compatible with Word97-2003”. But what use is this if I am using OOXML in another application like OpenOffice or WordPerfect Office? What if I want to disable UI functionality that is not compatible with OpenOffice 1.5? Or WordPerfect 8? Or any other application? Where is the ability for other implementations to specify their preferences? 
Define this an application neutral way. If it is truly a Word-only feature, then remove it from OOXML and express as an application-defined extension according to the extensibility mechanisms of Part 5.  
  Part 4, Section 2.15.3.6 page 1378, lines 12-17 te This is the “autoSpaceLikeWord95” element, which is defined as "This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 95) when determining the spacing between full-width East Asian characters in a document's content."

No further detail is give, so no one but Microsoft will be able to implement this feature.

Define the intended behavior.

We appreciate that this element is intended for backwards compatibility and is optional. However, if a vendor does want to fully implement the standard, for example, in order to read and display all OOXML documents, then this definition is insufficient.

On the other hand, if we think that no other vendor will fully implement this specification, then this brings into question its suitability for an International Standard.

 
  Part 4, Section 2.15.3.63 page 1481, lines 9-14 te This is the "useWord2002TableStyleRules" element defined as, "This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 2002) when determining the formatting resulting from table styles applied to tables within a WordprocessingML document."

No further definition is of the expected behavior is given.

Define the intended behavior.

We appreciate that this element is intended for backwards compatibility and is optional. However, if a vendor does want to fully implement the standard, for example, in order to read and display all OOXML documents, then this definition is insufficient.

On the other hand, if we think that no other vendor will fully implement this specification, then this brings into question its suitability for an International Standard.

 
  Part 4, Section 2.15.3.64 page 1482, lines 10-15 te This is the “useWord97LineBreakRules” element, which is defined in these terms, "This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 97) when determining the line breaking rules for East Asian text within a WordprocessingML document."

No further definition is of the expected behavior is given. This is insufficient.

Define the intended behavior.

We appreciate that this element is intended for backwards compatibility and is optional. However, if a vendor does want to fully implement the standard, for example, in order to read and display all OOXML documents, then this definition is insufficient.

On the other hand, if we think that no other vendor will fully implement this specification, then this brings into question its suitability for an International Standard.

 
  Part 4, Section 2.15.3.65 page 1483, lines 16-21 te This is the “ wpJustification” element, which is defined as "This element specifies that applications shall emulate the behavior of a previously existing word processing application (WordPerfect 6.x) when performing full paragraph justification using a val attribute value of both on the jc element (§2.3.1.13). This alternate justification method involves biasing towards compressing rather than expanding spaces when needed to justify a line."

No further definition is of the expected behavior is given. This is insufficient.

Define the intended behavior.

We appreciate that this element is intended for backwards compatibility and is optional. However, if a vendor does want to fully implement the standard, for example, in order to read and display all OOXML documents, then this definition is insufficient.

On the other hand, if we think that no other vendor will fully implement this specification, then this brings into question its suitability for an International Standard.

 
  Part 4, Section 2.15.3.66 - te This is the “wpSpaceWidth” element, which is defined in only the briefest terms, merely: "Set the width of a space like WordPerfect 5.x."

This is clearly insufficient.

Define the intended behavior.

We appreciate that this element is intended for backwards compatibility and is optional. However, if a vendor does want to fully implement the standard, for example, in order to read and display all OOXML documents, then this definition is insufficient.

On the other hand, if we think that no other vendor will fully implement this specification, then this brings into question its suitability for an International Standard.

 
  Part 4, Section 2.16     Fields are represented as a non-XML embedded format in OOXML. However, not extensibility mechanism seems to have been provided. For example, no namespace support is described in fields, so it is impossible for vendors to add support for their features to fields.

Considering that the presented set of field options are taken from a single vendor's legacy format without regard for the feature sets and requirements of other vendors, the inability for application-defined extensions is a serious design flaw.

Provide a mechanism for vendor defined extensions in fields including field types, field arguments and switches.  
  Part 4, Section 2.16.5.1 ADDRESSBLOCK page 1509, line 6 te Definitions of \c and \e are inconsistent. More specifically, the behavior when there are are multiple \e instances provided is undefined. Clarify this how this mechnanism works when multiple \e's are provided.  
  Part 4, Section 2.16.5.1 ADDRESSBLOCK page 1509, line 6 te The definition of the \d switch refers two undefined behaviors, namely international postal address formats. Define the \d switch fully. International addressing conventions are well-established by the Universal Postal Union which publishes guidelines for 180+ nations. OOXML should be using these guidelines.  
  Part 4, Section 2.16.5.1 ADDRESSBLOCK page 1509, line 6 te The definition of the \f switch says that it "specifies the name and address format by providing a template of merge-field placeholders" However, no description of this template format is given. Define  
  Part 4, Section 2.16.5.1 ADDRESSBLOCK page 1509, line 6 te The definition of the \l switch makes two references to 'Language ID', which is not defined in this context. OOXML in other places defines several different types for representing languages. Which ones is intended here? Define the \l switch fully.  
  Part 4, Section 2.16.5.10 BARCODE   te "POSTNET" and "Facing Identification Mark (FIM)" are undefined terms in this standard. Define 'BARCODE' fully, likely by providing an external normative reference to the source of the POSTNET and FIM specifications.  
  Part 4, Section 2.16.5.10 BARCODE     This feature will not work outside of the United States, since it is hard-coded to only specify barcode formats used by the US Postal Service. Other systems in use in other countries, such as the Royal Mail's "Mailsort" system. Generalize the BARCODE feature to allow global use.  
  Part 4, Section 2.16.5.10 BARCODE     POSTNET, as used by the US Portal Service is obsolete and will be replaced by OneCode in 2009. Add support for OneCode in this. This cannot wait for the mainteenance update of DIS 29500.  
  Part 4, Section 2.16.5.18 DATE   te These section lacks cultural adaptibility. It includes support for only the Gregorian, Saka Era (Hindu), and Hirji (Islamic) calendars. Other systems are in wide use, include the Iranian Jal*li Calendar, the Hebrew Calendar and the Javanese Calendar. Define this field in a way that allows the expression of all calendar systems in use by ISO nations today.  
  Part 4, Section 2.16.5.2 ADVANCE page 1509, lines 10-12 te The definition of 'ADVANCE' is insufficient: "Moves the starting point of text that follows the field to the right or left, up or down, or to a specific horizontal or vertical position"

What is the "text that follows the field?"

The problem is that there are three concepts of ordering: the lexical ordering of the XML document, the XML document ordering (an XML specific concept), and a presentation ordering, of how a document displays on the screen.

The existence of something like ADVANCE permits the lexical ordering of content to be different from the presentation ordering. So when the behavior of ADVANCE is defined in terms of ordering ("Moves the starting point of text that follows the field") this is ambiguous. Are we talking about lexically following or presentation following? This needs to be defined. This is an important concern when you have multiple ADVANCE fields.

Define ADVANCE fully.  
  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. There should be specified at least a small set of interoperable formats.  
  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. Define how pictures are named.  
  Part 4, Section 2.16.5.34 - te 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. There should be specified at least a small set of interoperable formats.  
  Part 4, Section 2.16.5.34 - te 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. 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. Provide a proper external normative reference for the XSLT which is allowed here.  
  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? UNC? The example given has a DOS file path, a construct which is not portable. Define how documents are named.  
  Part 4, Section 2.16.5.40 LISTNUM page 1544, line 2 te This table, with no headers provided, is confusing. What is this table trying to tell? Clarify this table.  
  Part 4, Section 2.16.5.5 AUTONUM page 1512, lines 11-12 te According to the text, the AUTONUM field is deprecated. A new standard should avoid deprecated parts.

Why cannot legacy documents, when converted to OOXML, be modifed to use the LISTNUM field? Can't LISTNUM represent everything that AUTONUM can? If not, why can't we then extend the capabilities of LISTNUM so it handles all of the functionality needed?

The issue is that having two different ways of accomplishing the same thing creates extra burdens for OOXML consuming applications, without any benefit to the user or the vendor. It is just extra work.

This is a general theme. Compatibility with legacy documents does not require that OOXML be identical to every option of the legacy format, but just that there must be a mapping.

Remove AUTONUM  
  Part 4, Section 2.18.106 - te Length is said to be “exactly 1 character”. This is inconsistent with the earlier language and the schema fragment given which defines it as being 1 octet long or two characters.

This appears to be caused by a confusion of octets and characters. According to the W3C's XML Schema standard, xsd:hexBinary data is measured in octets, not characters.

Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
             
  Part 4, Section 2.18.4 - te The reproduction of the artwork provided here is of poor quality providing. Some of the images, such as 'apples' or 'balloons3Colors' show artifacts, where extraneous lines or blotches appear. These graphics should be provided in standalone file form, preferably in a scalable graphics format.  
  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.

The set of clipart used in border styles is something best left to the discretion of the vendor, a vendor who may be targetting a specific geographic market. We would like to see the current closed list of clipart be made extensible. One way to do this would be to include the actual graphic of the border in the document as a binary part.

Provide an interoperable extensibility mechanism for a document author or application to specify their own art border graphics.  
  Part 4, Section 2.18.45 - te Length is said to be “exactly 3 characters”. This is inconsistent with the example given which has a length of 6 characters.

This appears to be caused by a confusion of octets and characters. According to the W3C's XML Schema standard, xsd:hexBinary data is measured in octets, not characters.

Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
  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.

This may be another case of confusion between characters and octets.

Reconcile the description of the type with the enumerated values.  
  Part 4, Section 2.18.57 - te The description of this type says it contains four hexadecimal digits, four hexadecimal octets and exactly four characters. These definitions are not compatible. A hexadecimal octet is two hexadecimal digits.

This appears to be caused by a confusion of octets and characters. According to the W3C's XML Schema standard, xsd:hexBinary data is measured in octets, not characters.

Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
  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.  
  Part 4, Section 2.18.66 “chicago” te 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.  
  Part 4, Section 2.18.66 “decimalEnclosedFullstop” te The example given does not show enclosed characters and so contradicts the normative text. Reconcile the text and the example.  
  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.  
  Part 4, Section 2.18.66 “numberInDash”, etc. te 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. Specify the intended dash explicitly.  
  Part 4, Section 2.18.66 - te The numeration 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. Include explicit support for all numeration formats in use by ISO nations.  
  Part 4, Section 2.18.72 - te Length is said to be “exactly 10 characters”. This is inconsistent with the example given which has a length of 20 characters.

This appears to be caused by a confusion of octets and characters. According to the W3C's XML Schema standard, xsd:hexBinary data is measured in octets, not characters.

Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
  Part 4, Section 2.18.86 - 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.

This appears to be caused by a confusion of octets and characters. According to the W3C's XML Schema standard, xsd:hexBinary data is measured in octets, not characters.

Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
  Part 4, Section 2.2.1 background (Document Background) page 27, lines 8&21 te The example starts by saying, "Consider a document which utilizes a gradient fill background moving between black and the accent5 theme color" and then proceeds to give example markup referring to accent3 rather than accent5.

The example does not do what the text says it does.

Fix the contradiction.  
  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  
  Part 4, Section 2.8.2.2 “0xEE” te This value is said to signify “an Eastern European character set”. There is no such thing. First, “Eastern Europe” is not unambiguously delineated. Second, this region uses many character scripts, including Roman, Cyrillic, Arabic, Armenian, etc. Explain what is meant by, “an Eastern European character set”.  
  Part 4, Section 2.8.2.2   te The default character set is said to be “the ANSI character set”. But ANSI has standards for many character sets. Do you mean ANSI 209-1992 “Matrix Character Set for OCR”? Probably not. So a normative reference to a specific standard is required. Provide normative reference for “the ANSI character set”.  
  Part 4, Section 3.17 throughout te Many of the financial functions rely on a “date count basis” value that is not defined in this standard. Without this level of definition implementors will not be able to evaluate these functions. Provide a full definition of “day count basis”, in particular with respect to treatment of leap years and leap days.  
  Part 4, Section 3.17 throughout ed The mathematical formula in the PDF version of the standard in many places is unreadable and compares very poorly with the clarify of the rest of the text and most other images. Provide better quality mathematical formula.  
  Part 4, Section 3.17.4 Dates and Times 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.  
  Part 4, Section 3.17.4 Dates and Times page 2522, lines 6, 7 & 9 te The text says, "Numerous functions take as arguments one or more serial values or strings representing dates and/or times." However, the supported string forms which can represent dates and/or times is not specified.

It should be noted that there are many different possible date/time representations in English and even more when other languages are taken into account, So lacking definition in this area will prevent interoperability,

The request remains that OOXML define the string forms of dates and times. What forms are allowed? Interoperability between different OOXML applications will suffer greatly if the lexical form of times and dates are not fully defined.

It should be appreciated that the use of ISO 8601 would have made this unnecessary.

 
  Part 4, Section 3.17.4.1 Date Representation page 2522, lines 19 te The text proposes a dual date base system (1900/1904). There is no way to specify a date before 1900.

Microsoft is certainly entitled to produce a product (Excel) that does not allow the use of dates before 1900. But this should not prevent other vendors from using OOXML to specify a wider range of dates and to express them correctly.

As defined today, OOXML allows dates from 1900 to 9999. So, it allows dates only 100 years into the past, but allows dates 7,000 years into the future. How is that beneficial to anyone? There are people alive today, receiving health care, pensions, housing allowences, etc., who were born before 1900. Their date of birth cannot be represented in the spreadsheet format defined by DIS 29500. This makes OOXML inapplicable for several sectors of the economy, including healthcare.

We should also note that several vendors who have expressed interest in implementing OOXML have products that allow dates earlier than 1900. For example Novell's version of OpenOffice allows dates back to 1 AD. And Corel's QuattroPro allows dates back to 1800. (OpenOffice also calculates leap years correctly in 1900). So for these reasons, we believe that we must raise concerns over OOXML's treatment of spreadsheet dates.

Allow a vendor-defined per-document date origin. This would allow Microsoft to support their 1900/1904 bases, but also allow other vendors the ability to support earlier dates when they need to.

For example, we could have a single attribute called dateBase and allow an implementation to set any ISO 8601 date value as the base date. This could be 1900 or 1904 or any other date. In addition there could be a boolean value called treat1900AsLeapYear, with default value of false. Microsoft can set this to true for their legacy sheets, but everyone else can use the default.

If we do this, Microsoft can fully 100% represent all of their legacy spreadsheets, including the date bugs, but the rest of the world can do what makes sense for them, including matching Excel, if they wish.

 
  Part 4, Section 3.17.6.7   te This calls for the date serial number to be stored, “as accurately as possible”. This requirement is not precise and is untestable. Further, “as accurately as possible” may entail the use of codes such as arbitrary precision arithmetic, etc. which would have large performance penalties. State the minimum precision required.  
  Part 4, Section 3.17.7.101 DURATION ed The function is defined in terms of $100 par value, but there is nothing about the bond calculations that is inherently tied to the US Dollar. Recommend the use of the generic currency sign here (U+00A4)  
  Part 4, Section 3.17.7.201 LOWER te This function is ambiguous. Is it asking for a lexical, character by character conversion to lowercase? Or for a whole-word conversion? For example, Greek capital Sigma has two lower case forms, one reserved for use as the terminal letter in a word. As written, it is not clear whether this function should be implemented to take that into consideration or not. Clarify what it means to convert to lower case.  
  Part 4, Section 3.17.7.206 MDURATION ed The function is defined in terms of $100 par value, but there is nothing about the bond calculations that is inherently tied to the US Dollar. Recommend the use of the generic currency sign here (U+00A4)  
  Part 4, Section 3.17.7.207 MEDIAN te The text currently says, “If there is an even number of numbers in the set, MEDIAN calculates the average of the two numbers in the middle”. This is ambiguous. Middle of what? Middle of the range is the most direct interpretation. Probably want something more like, “The values in the range are logically ranked from lowest to highest and the middle number is returned. If there is an even number of numbers in the set...” Clarify the definition.  
  part 4, Section 3.17.7.227 NORMINV te This text says, “NORMINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. Keep the suggestions, but put them in informative Notes or Guidance.  
  Part 4, Section 3.17.7.229 NORMSINV te This text says, “NORMSINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. Keep the suggestions, but put them in informative Notes or Guidance.  
  Part 4, Section 3.17.7.243 OR te It is not specified whether this function short-circuits or not. In other words, must the remaining arguments be evaluated once one of them is found to be TRUE? Since some functions have side effects, it is necessary to define this in order to ensure interoperability. Specify whether this function allows short-circuit evaluation.  
  Part 4, Section 3.17.7.244 PEARSON te The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. Correct the text  
  Part 4, Section 3.17.7.280 RSQ te The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. Correct the text  
  Part 4, Section 3.17.7.282 SEARCH/SEARCHB te Is this a lexical comparison or collation-based search? Clarify the basis for string comparisons  
  Part 4, Section 3.17.7.287 SINE te It is not indicated whether the parameter is in radians or degrees Specify the angular units that this parameter is in  
  Part 4, Section 3.17.7.291 SLOPE te The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. Correct the text  
  Part 4, Section 3.17.7.296 STDEV te The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. Correct the text  
  Part 4, Section 3.17.7.297 STDEVA te The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. Correct the text  
  Part 4, Section 3.17.7.298 STDEVP te The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. Correct the text  
  Part 4, Section 3.17.7.299 STDEVPA te The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. Correct the text  
  Part 4, Section 3.17.7.300 STEYX te The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. Correct the text  
  Part 4, Section 3.17.7.313 TAN te It is not indicated whether the parameter is in radians or degrees Specify the angular units that this parameter is in  
  Part 4, Section 3.17.7.335 VAR te The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. Correct the text  
  Part 4, Section 3.17.7.336 VARA te The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. Correct the text  
  Part 4, Section 3.17.7.337 VARP te The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. Correct the text  
  Part 4, Section 3.17.7.338 VARPA te The definition of the argument in the function is incorrect. It should say that x-bar is the sample means, not x. Correct the text  
  Part 4, Section 3.17.7.34 CELL te The list of values supported for the “format” argument is far shorter than the list of possible numeric formats. What happens if CELL(“format”, A1) is called on a cell with a format not on this list? Specify what happens in this case.  
  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.

A standard that requires incorrect date calculations -- verifiable facts -- is unacceptable.

Remove the text that defines behavior that results in incorrect date calculations.  
  Part 4, Section 3.17.7.344 WORKDAY te This function is defined to skip over weekends in its calculations, but weekend is not defined and has different definitions in different parts of the world. Define this function unambiguously and preferably in a way which provides for cultural adaptability in the definition of a weekend.  
  Part 4, Section 3.17.7.348 YEARFRAC te This function is ambiguous. Specifically it does not treat the calculation in the presence of leap years. In the Actual/Actual basis, do we ever divide by 366? Or only by 365? Would we divide by 366 only if the leap day is between start-date and end-date? Of either start-date or end-date are in the leap year? If both start-date and end-date are in a leap year? Clarify the definition of the function when involving leap years.  
  Part 4, Section 3.17.7.35 CHAR te This function maps between numbers and characters. But this mapping must be defined b y a character set and none is defined here. Specify what character set is used for this mapping.  
  Part 4, Section 3.17.7.37 CHIINV te This function says, “CHIINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted. Keep the suggestions, but put them in informative Notes or Guidance.  
  Part 4, Section 3.17.7.38 CHITEST te The definition of this function says the the results are “unspecified” if the two ranges do not have the same number of points. But isn't this a clear argument error where should be returned? Surely we can document what Excel does here? Specify the required results for the case where the two ranges are of unequal size.  
  Part 4, Section 3.17.7.4 ACOS te It is not indicated whether the returned value shall be in radians or degrees Specify the angular units that should returned  
  Part 4, Section 3.17.7.47 CONFIDENCE te This function cannot be calculated without making an assumption about the distribution of the data? Are we assuming normally distributed data? uniformly distributed data? Make the distribution assumptions explicit.  
  Part 4, Section 3.17.7.48 CONVERT te This function is ambiguously defined, especially with regards to the traditional units of measure. For example, a tablespoon is 15ml in the US, but 20ml in Australia. Which is meant here? Similarly, a cup is defined differently in various countries, e.g. 8 oz in US, except the FDA defines it for food labeling purposes as 240ml, while it is 250ml in Australia and 285ml in the UK. Refine the definition of this function, especially with respect to pre-metric measures so as to remove ambiguity.  
  Part 4, Section 3.17.7.49 CORREL te The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. Correct the text  
  Part 4, Section 3.17.7.50 COS te It is not indicated whether the parameter is in radians or degrees Specify the angular units that this parameter is in  
  Part 4, Section 3.17.7.63 COVAR te The definition of the arguments in the function is incorrect. It should say that x-bar and y-bar are the sample means, not x and y. Correct the text  
  Part 4, Section 3.17.7.65 CUBEKPIMEMBER te The “kpi-property” parameter lists a number of values which are undefined such as “temporal context”, “relative importance”, etc. This is made even more cryptic by the fact that this function, unlike almost all the others, has examples that fail to illustrate the returned values. If there is to interoperability in the use of this function, semantics in additional to syntax will need to be specified. Provide the semantics for this function  
  Part 4, Section 3.17.7.65 CUBEKPIMEMBER te The definition of this function says that it retrieves an OLAP Cube from a “SQL Server”. Surely this function is not limited to use only against Microsoft database servers? Provide a vendor-neutral definition of this function.  
  Part 4, Section 3.17.7.66 CUBEMEMBER te This function refers to, “A multidimensional expression (MDX) that evaluates to a unique member in the cube”. But MDX is undefined. Define the syntax and semantics of an MDX  
  Part 4, Section 3.17.7.76 DATEVALUE te This function says that it can take a string in any valid date and/or time format. It further says that if the year portion of the input string is ommitted, that the current year is used. But what if the date is omitted as well, e.g, someone passes in a pure time string like “10:34”? Do we assume the current date? Or assume January 1st of the current year? Resolve the ambiguity in the definition when a string with time format is passed in.  
  Part 4, Section 3.17.7.77 DAVERAGE te Normative information regarding the processing of “an entire column in a database” is placed in an informative note. Since it is clearly stating a requirement in the processing this should be in the normative text. Rework the note into the normative description of this function.  
  Part 4, Section 3.17.7.78 DAY te The function does not define what a “Gregorian day” is, nor why it would be different in the 1900 versus 1904 date bases for a date in 1982. Is this just returning the day of the month? Why would this function return two values for that in 1982? Define fully what this function returns.  
  Part 4, Section 3.17.7.9 AND te It is not specified whether this function short-circuits or not. In other words, must the remaining arguments be evaluated once one of them is found to be FALSE? Since some functions have side effects, it is necessary to define this in order to ensure interoperability. Specify whether this function allows short-circuit evaluation.  
  Part 4, Section 3.17.7.91 DISC ed The function is defined in terms of $100 face value, but there is nothing about the security discounting that is intrinsically tied to the US Dollar. Recommend the use of the generic currency sign here (U+00A4)  
  Part 4, Section 3.17.7.95 DOLLARDE te This function is ambiguously defined. Specifically we need to know how many decimal digits we need to look at to determine the numerator of the fraction. The example given DOLLARDE(1.02,16) = 1+ 2/16. But what about, after a serious of calculations and in the presence of accumulated floating point error we have DOLLARDE(1.020000001, 16)? Is this now 1 + 20000001/16? or 1,250,001? Also the definition is worded incorrectly. The first parameter is not “a number expressed as a fraction.” It is “a numbered interpreted as a fraction”. Also, the information marked as “Note” seems to be the most critical part of the definition and so should be part of the normative material. Clarify how this function works  
  Part 4, Section 3.17.7.96 DOLLARFR te The information marked as “Note” seems to contain the only definition of what this function actually should do, so it should be made part of the normative material. Rework the note into the normative description of this function.  
  Part 4, Section 3.18.86 - te Length is said to be “exactly 4 characters”. This is inconsistent with the schema fragment given which defines it as being 4 octets long or 8 characters.

This appears to be caused by a confusion of octets and characters. According to the W3C's XML Schema standard, xsd:hexBinary data is measured in octets, not characters.

Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
  Part 4, Section 3.18.87 - te Length is said to be “exactly 2 characters”. This is inconsistent with the schema fragment given which defines it as being 2 octets long.

This appears to be caused by a confusion of octets and characters. According to the W3C's XML Schema standard, xsd:hexBinary data is measured in octets, not characters.

Correct the definition of this attribute.  
  Part 4, Section 3.2.29 pg. 1916 te The conversion from input password to single byte string is ambiguous. Certainly the input password could contain characters from more than one script, say some Korean, some Chinese. Do we process via multiple DBCS code pages? Or just one and then replace the unmapped characters with 0x3F? If only one DBCS code page is used, how is that determined in this case? Clarify this processing, especially for passwords that use characters from more than one script.  
  Part 4, Section 3.2.29 pg. 1916 te This seems to imply that if a password is entered in a script like Armenian or Ethiopic then the characters will be replaced all by a single character 0x3F, making the password protection feature useless. This is unacceptable. Remedy so password hashes can be calculated on any Unicode password.  
  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.  
  Part 4, Section 3.2.29 p. 1917-1922 te No normative description of the password hashing algorithm is provided, so interoperability of this feature cannot be assumed. In an informative section, 5-pages of C-language source code is provided as “an example”, and this appears to involve machine-dependent bit manipulations.

Further this example source code will not even compile! It refers to types such as WCHAR, byte, WORD, which are not intrinsic C/C++ types and are not defined in the code.

As our other comments on this clause indicate, there appears to have been no effort made by the authors to define this in a platform and machine netural way.

Provide a normative, cross-platform definition of the hashing algorithm. Cross-platform source code can be given as an example, but the normative text should be in English, not in a programming language.

We recommend that algorithms be defined in text, not merely illustrated in code. This ensures portability.

 
  Part 4, Section 3.3.1.69 - te 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. Provide a normative, cross-platform definition of the hashing algorithm. Cross-platform source code can be given as an example, but the normative text should be in English, not in a programming language.  
  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 in the context of this attribute. 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.  
  Part 4, Section 3.3.1.69 - te A hash algorithm is provided, likely based on a legacy algorithm used in Excel. This legacy algorithm is known to be a weak algorithm and has effectively been cracked.

One could argue that no hash algorithm would be effective in OOXML, since a user could simply unzip the document and hand edit the XML to remove the hash or to set it to some known value. However, some application types such as online editing via Google Docs, or other similar applications, can secure physical access to the document via other means. Editing access to the document does not necessarily presuppose physical access to the document's XML. So there is a necessity for a secure & interoperable hash algorithm, such as SHA-256 for document protection.

Use a standard hash algorithm as the default, such as SHA-256 Legacy hash algorithms should be supported via the defined extension mechanism.

We have no objection to the inclusion of the legacty algorithm, but we do want the default alrgorithm, which will be used by new documents, to be standards-based and secure.

 
  Part 4, Section 5.1.12.28 - te Length is said to be “exactly 3 characters”. This is inconsistent with the schema fragment given which defines it as being 3 octets long or 6 characters.

This appears to be caused by a confusion of octets and characters. According to the W3C's XML Schema standard, xsd:hexBinary data is measured in octets, not characters.

Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
  Part 4, Section 5.1.12.37 - te Length is said to be “exactly 10 characters”. This is inconsistent with the schema fragment given which defines it as being 10 octets long.

This appears to be caused by a confusion of octets and characters. According to the W3C's XML Schema standard, xsd:hexBinary data is measured in octets, not characters.

Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
  Part 4, Section 5.1.3.4 - te 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. Provide an external reference for the version(s) of QuickTime format intended here as well as an interoperable codec.  
  Part 4, Section 6. VML Reference Material pages 4343-4960 te VML is a deprecated markup language for vector graphics that was rejected by the W3C almost a decade ago. The W3C's Scalable Vector Graphics markup is the pre-existing and more widely used standard in this area.

We acknowledge that Microsoft may wish to use VML for legacy purposes, but this needs to be balanced by the desire of others to use the more recognized SVG format.

Allow SVG for graphics wherever VML is allowed.  
  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.  
  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.  
  Part 4, Section 6.2.2.14 - te This describes an "ink" element which stores "ink annotations in an application-defined format." This is apparently intended to store annotations, used with tablet input devices to add hand-written annotations to documents. These annotations are often a vital part of documents and their specification is undefined in OOXML. We are opposed to standardizing placeholder elements for entirely application-dependent proprietary formats without also specifying an interoperable format for those who with to create interoperable formats. Specify the “ink” format or remove the element from OOXML and make this an application extension using the extensibility mechanisms of OOXML.  
  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.  
  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.

The enumeration is a closed list. You cannot add another format type without making the XML invalid.

Several options here, but the desire is to allow cross platform interoperability. For example, this type could be defined as a union of the given enumeration with an xsd:string to allow greater flexibility.  
  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 It is recommended that this section be removed from OOXML and that the proposers of OOXML work within the W3C's MathML activity, where MathML 3.0 is currently being drafted, to produce a single standard for equations that can be used later referenced by a future version of OOXML.

At the very least 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.

 
  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.

We would like to see the standard changed to explicity contain support for Linux, not by non-portable application-defined extensions, but natively as part of the defined schema.

Several options here, but the desire is to allow cross platform interoperability. For example, this type could be defined as a union of the given enumeration with an xsd:string to allow greater flexibility.  
  Part 4, Section 7.4.2.5 - te 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. Specify this so interoperability may be achieved.  
  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.  
  Throughout - te The name "Office Open XML" is often mistakenly called 'Open Office XML” implying a connection to the OpenOffice project which does not exist. This naming confusion has been documented and has occurred numerous times, including by analysts and even in Microsoft press releases and blogs. Since “Open Office” is the pre-existing name, by 6 years, Ecma should choose a new name, less apt to continue this confusion. Change the name of Office Open XML to a name which is not confused with OpenOffice.  
      ge More than 10% of the examples shown in the specification are not valid XML. See for example, this study by a BSI member: http://surguy.net/articles/ooxml-validation-and-technical-review.xml  

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

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

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

page


Top