1 2 (3) 4 5 (6) (7)
MB1 
Clause No./ 
Subclause No./ 
Annex 
(e.g. 3.1)
Paragraph/ 
Figure/Table/Note 
(e.g. Table 1)
Type of com-ment2 Comment (justification for change) by the MB Proposed change by the MB Secretariat observations 
on each comment submitted

US     ge The US National Body would like to note that, in accordance with the JTC 1 fast track process, any National Body voting on the DIS 29500 fast track ballot will have the option of reaffirming or changing their vote based upon the final text for DIS 29500.    
US     ge Referencing of unexplained backward compatibility modes  pose a problem for third party implementers    
US     ge The use of proprietary file formats within the Office Open XML standard appears to cause potential intellectual property ownership concerns.    
US Office Open XML Overview - ge This document is not listed as part of the Ecma 376 standard in the Forward to Part I “Fundamentals” and its status whether informative or normative is not explicitly stated. Clarify the status of this Overview document. If it is merely a promotional whitepaper about Ecma 376, then it should not be included in the published standard.  
US OpenPackagingConventions-RELAXNG.zip - ge This annex was not provided in a humanly-readable format as required by JTC1 Directives 8.3.5 and Annex H The annex should be provided in a humanly readable, lined-numbered format so it can be referenced and cited. Additionally, an electronic machine readable version can be provided according to Annex H  
US OpenPackagingConventions-XMLSchema.zip - ge This annex was not provided in a humanly-readable format as required by JTC1 Directives 8.3.5 and Annex H The annex should be provided in a humanly readable, lined-numbered format so it can be referenced and cited. Additionally, an electronic machine readable version can be provided according to Annex H  
US OfficeOpenXML-DrawingMLGeometries.zip - ge This annex was not provided in a humanly-readable format as required by JTC1 Directives 8.3.5 and Annex H The annex should be provided in a humanly readable, lined-numbered format so it can be referenced and cited. Additionally, an electronic machine readable version can be provided according to Annex H  
US OfficeOpenXML-RELAXNG.zip - ge This annex was not provided in a humanly-readable format as required by JTC1 Directives 8.3.5 and Annex H The annex should be provided in a humanly readable, lined-numbered format so it can be referenced and cited. Additionally, an electronic machine readable version can be provided according to Annex H  
US OfficeOpenXML-SpreadsheetMLStyles.zip - ge This annex was not provided in a humanly-readable format as required by JTC1 Directives 8.3.5 and Annex H The annex should be provided in a humanly readable, lined-numbered format so it can be referenced and cited. Additionally, an electronic machine readable version can be provided according to Annex H  
US OfficeOpenXML-XMLSchema.zip - ge This annex was not provided in a humanly-readable format as required by JTC1 Directives 8.3.5 and Annex H The annex should be provided in a humanly readable, lined-numbered format so it can be referenced and cited. Additionally, an electronic machine readable version can be provided according to Annex H  
US OpenPackagingConventions-RELAXNG.zip - ge There is no explicit indication given as to whether this annex is informative or normative. See ISO Directives, Part 2, section 5.2.6 Clarify the status of this annex  
US OpenPackagingConventions-XMLSchema.zip - ge There is no explicit indication given as to whether this annex is informative or normative. See ISO Directives, Part 2, section 5.2.6 Clarify the status of this annex  
US OfficeOpenXML-DrawingMLGeometries.zip - ge There is no explicit indication given as to whether this annex is informative or normative. See ISO Directives, Part 2, section 5.2.6 Clarify the status of this annex  
US OfficeOpenXML-RELAXNG.zi - ge There is no explicit indication given as to whether this annex is informative or normative. See ISO Directives, Part 2, section 5.2.6 Clarify the status of this annex  
US OfficeOpenXML-SpreadsheetMLStyles.zip - ge There is no explicit indication given as to whether this annex is informative or normative. See ISO Directives, Part 2, section 5.2.6 Clarify the status of this annex  
US OfficeOpenXML-XMLSchema.zip - ge There is no explicit indication given as to whether this annex is informative or normative. See ISO Directives, Part 2, section 5.2.6 Clarify the status of this annex  
US Part 1, Section 2.1 “Goal” - ge There are no normative statements in this clause, though Section 2 is indicated to be normative Mark clause as informative using one of the mechanisms of Section 7  
US Part 1, Section 2.2 “Issues” - ge There are no normative, statements in this clause though Section 2 is indicated to be normative Mark clause as informative using one of the mechanisms of Section 7  
US Part 2 - ge Part 2 defines Open Packaging Conventions (OPC) in terms that, according to Part 1, Section 9.1 Constraints on Office Open XML's Use of OPC, are more general than needed for the purpose of OOXML. This is due to bring confusion, and should be resolved. Part 2 should be amended either by: a) referencing an established standard (in which case placing documented constraints upon its use in OOXML would be fine), or else b) tightening Part 2 contents so as to keep it focused on OOXML related matters, or else c) submit OPC as a separate packaging-focused standard and, provided that it is accepted as a standard, apply option a) to it.

See Scope-Durusau-11.

 
US Part 4, Section 5.1.12.37 - ge Why are there several different definitions for a Panose value, both in Word Processing ML as well as Drawing ML? Since they are exactly the same they should be defined once in a shared schema.  
US general   ge,te Document should be restructured as a multi-part document.  It appears that one can claim conformity, independently, to some of the parts.  Part 3 should be a technical report, the other parts should be an international standard. Call the parts 29500-1, 29500-2, etc.  
US Part 4   te Unable to associate (multi-level) table cells with their headers.  

In tables that contain multiple levels of row and column headers, there is no way to associate a table cell with the specific column and row headers that apply to it. As such tables are very complex to navigate in a serialized manner (e.g., auditorily through a screen reader) given, for example, natural limits on human short-term memory, allowing a person with a visual impairment to be able to keep track of where they are in such a table is essential.

This is also necessary to assist users with short-term memory impairments. Other visual impairments, while not requiring the use of a screen reader, make

it difficult to visually track across a row or column in a multi-level table from a cell to its header label and back, to look this up. It must always be possible to retrieve the column and row labels that denote a designated position in a table.  

This is a requirement for Section 508 of the Rehabilitation Act and can be found in the standards at CFR1194.22(h). 

(http://atrc.utoronto.ca/index.php?option=com_content&sectionid=14&task=view&hidemainmenu=1&id=371

Refer to Section 4.3.)

Implement similar functionality to the <id> attribute of the <th> tag and <headers> attribute of the <td> tag from HTML 4.01. 
 

http://www.w3.org/TR/html401/struct/global.html#adef-id 

Refer to 7.5.2 Element identifiers: the id and class attributes. 
 

http://www.w3.org/TR/html401/struct/tables.html#edef-TH 

    Refer to 11.2.6 Table cells:  The TH and TD elements

 
US Part 4   te No logical tab or navigation order through links, presentation elements, form controls and objects. 

Tab or navigation ordering is essential in forms which must be reorganized (as described in Section 1.1) to allow the form elements to be presented to the user in an order that makes sense. In many cases, without proper ordering of form fields, there is no way to determine the intended meaning of a field, even when given its associated label.   

This is not a specific technical standard from Section 508, however failure to meet this requirement would cause functional performance requirements from CFR1194.31(a) not to be met. 

(http://atrc.utoronto.ca/index.php?option=com_content&sectionid=14&task=view&hidemainmenu=1&id=371

Refer to Section 4.4.)

Implement similar functionality to <tabindex> from HTML 4.01. 

http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex 

Refer to 17.11.1 Tabbing navigation

 
US Part 4   te Alternate text descriptions for image maps not supported.  

Specifying alternate text descriptions for individual regions of image maps is not fully supported. So any interactive document that requires clicking on an image region (for example, one displaying a map and asking the user to click on their state or province) cannot be made accessible.  

This is a requirement for Section 508 of the Rehabilitation Act and can be found in the standards at CFR1194.22(e and f).   

(http://atrc.utoronto.ca/index.php?option=com_content&sectionid=14&task=view&hidemainmenu=1&id=371

Refer to Section 4.5.)

Implement similar functionality to <alt> attribute of the area shape tag per HTML 4.01.   

http://www.w3.org/TR/html401/struct/objects.html#adef-alt 

Refer to 13.8 How to specify alternate text.

 
US Part 4   te No context and orientation for frames. 

In many documents, non-textual content is put into special regions enclosed by their own “frames”. As the format of the content in these regions tends to be “special”, it tends to be less accessible . Thus, it is important to be able to provide alternative text descriptions for frames as well as information

as to how the frame fits into the document context and relates to other frames (including the main text frame) in terms of navigation order and other semantic relationships. OOXML does not support any of this.  

This is a requirement for Section 508 of the Rehabilitation Act and can be found in the standards at CFR1194.22(i) 

(http://atrc.utoronto.ca/index.php?option=com_content&sectionid=14&task=view&hidemainmenu=1&id=371

Refer to Section 4.8.)

Implement similar functionality of the <title> attribute of the <frameset> tag per HTML 4.01. 

http://www.w3.org/TR/html401/struct/global.html#adef-title 

Refer to 7.4.3 The TITLE attribute.

    Refer to 16.2.1 The FRAMESET element.

 
US Part 4, Section 2.16.17 page 1585 te There is no explicit relationship between a label and its associated form field (textInput - 2.16.33, checkBox - 2.16.7, and ddList – 2.16.7), nor is there

a way to specify the proper positioning of a label with respect to the form field. These have been

treated as distinct concepts in all electronic form applications, including Microsoft Access forms, for years.) This distinction becomes clear if one considers

the case of associating a single label with multiple form fields (for example, in “Check all that apply...” scenarios). Given the importance of accessible

forms, this issue alone is probably enough to warrant rejection of OOXML.  

This is a requirement for Section 508 of the Rehabilitation Act and can be found in the standards at CFR1194.22(n) and CFR1194.21(l). 

(http://atrc.utoronto.ca/index.php?option=com_content&sectionid=14&task=view&hidemainmenu=1&id=371

Refer to section 4.1.)

Implement similar functionality to the <label> tag and <for> attribute and the <id> attribute of form elements from HTML 4.01. 

http://www.w3.org/TR/html401/interact/forms.html#edef-LABEL 

17.9.1 The LABEL element 

http://www.w3.org/TR/html401/struct/global.html#adef-id 

7.5.2 Element identifiers: the id and class attributes

 
US Part 4, Section 2.15.1.94 and elsewhere   te Binary Information in the Office Open standard could lead to security concerns.  Specifically, this is concerning the use of non-Office Open XML specified cryptography.    
US Part 1, Section 2.4 “Document Conformance” line 22 te This line require conformance with “Unicode Standard” without specifying a version. XML 1.0 referred to Unicode 2.0, though the informative Appendix A of OOXML Part 1 lists Unicode 4.0. Which is it? An explicit Unicode version reference should be made in the Conformance section.  
US Part 1, Section 4 “Definitions” behavior, implementation-defined te “application-specific”, at least in common standards use, is not the same as application-defined, viz. ANSI C Programming Language Use “application-defined” consistently where the intent is for applications to document their behavior.  
US Part 1, Section 9.1.1 - te ASCII requires a normative reference since there are several national variations. Suggest reference be made to ISO/IEC 646:1983 or ANSI X3.4-1986  
US Part 1, Section 9.1.5 - te This sub-clause, buried in introductory material, negates a provision of the more detailed OPC specification in Part 2. This will likely be missed by implementors. If interleaving is not permitted then it should not be described in Part 2.  
US Part 1, Section 10.1.2 line 20 te Reference is made to material in Part 12, Clause 12. Although a clause of that number does exist, it does not contain the material 10.1.2 references it for. Correct the reference to point to the correct clause.  
US 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. Change lines 3-5 to read, “An alternative format import part allows content specified in an application-defined alternate format to be embedded directly in a WordprocessingML document...”  
US 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. Fully define the use of Custom Property Part  
US 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? Clarify the meaning.  
US 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 reference to intended specifications for TrueType and OpenType  
US 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. 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.  
US Part 1, Section 15.2.15 - te For there to be interoperability of this feature, it must either specify what size the thumbnail should be or state that the application will scale the image as needed. Specify whether the thumbnails have a fixed size (in units of pixels, for example), any size scaled to fit, or the behavior is implementation defined.  
US Part 1, Appendix   te The reference given for the Zip format does not provide a date or version, though this specification is frequently revised, Reference should be made to a particular dated and labelled version.  
US DIS 29500 including schemas   te Attribute Definitions: The attribute “val” has multiple definitions within the same schema, for instance, in dml-diagramLayoutVariables.xsd, it is defined with the type ST_NodeCount and boolean. Or in wml.xsd where it has the types, ST_Merge, ST_String, and, ST_TwipsMeasure. It has types defined elsewhere as string and ST_Xstring. Despite having only seven different types in the schemas, it has ninety (90) separate and distinct prose definitions in DIS 29500, Part 4. This is only by way of illustration. A survey of the first six hundred and seventy-seven (677) pages of Part 4 is attached as Annex B, which demonstrates that multiple distinct definitions are not uncommon in DIS 29500. Every attribute should have one and only one definition. Moreover, in the prose of the standard, that definition should be given once and only once. Even if a definition must be repeated, it should be the same definition in all cases.  
US DIS 29500 in its entirety   te Interoperability: DIS 29500 as written fails to establish interoperability between conforming applications that convert Microsoft Office 97 – 2003 documents to the format defined by this proposal. There is no defined mapping between Microsoft Office 97 – 2003 formats and the format defined by DIS 29500. In the absence of such a mapping, conversions to the defined format will be inconsistent therefore lead to a lack of interoperability between the resulting conversions. Moreover, the lack of a defined mapping defeats interoperability between applications that use the defined format and the existing installations of applications that use Microsoft Office 97 – 2003 formats, resulting in a lack of interoperability with existing applications. DIS 29500 be amended to include a reference to a mapping from the Microsoft Office 97 – 2003 formats, to OOXML.  
US Part 1, Sections 2.3, 2.4 and 2.5   te Syntactic Conformance: DIS 29500 only constrains syntactic conformance to the proposal. As a practical matter, this will result in applications that claim conformance to the proposal but which have in fact re-defined the semantics as defined in the proposal. This will lead to a lack of interoperability due to non-disclosed modification of the semantics as defined in DIS 29500. That Part 1, Section 2.3 be amended to include conformance to the semantics as defined by DIS 29500 to claim conformance to DIS 29500.  
US DIS 26500 in its entirety   te IRIs Not URIs: Users of XML and the WWW are no longer limited to Uniform Resource Identifiers (URIs) and can now use Internationalized Resource Identifiers (IRIs). IRIs were first proposed in 2003 and became RFC 3987 in January of 2005. As an international standard, DIS 29500 should conform to the use of IRIs in order to serve the international community. All references to URIs should be reformed (with necessary changes in other prose) to be to IRIs as defined by RFC 3987.  
US DIS 29500   te ISO 860: The term “Gregorian” calendar is used 44 times (upper and lower case) in Part 4 without any citation to ISO/IEC 8601, which defines the ISO standard for dates and times, as well as the Gregorian calendar. It is not clear if the use of the term “Gregorian” calendar is consistent with the definition given in ISO/IEC 8601. The DIS should define the term “Gregorian” calendar, with preference being given to referring to ISO/IEC 8601 and to documenting exceptions from that standard, as necessary.  
US DIS 29500   te Calendars: DIS 29500 makes reference to a number of calendars that are not further defined by reference to standards or defined by DIS 29500. In order to insure interoperability between applications, all calendars should be defined by references to standards for those calendars or defined within DIS 29500. The calendars in question are: Gregorian (localized) calendar, Gregorian Arabic Calendar, Gregorian Middle East French Calendar, Gregorian (U.S.) calendar, Gregorian Transliterated English calendar, Gregorian Transliterated French Calendar, Hebrew (Lunar) calendar, Hijri (Arabic Lunar Calendar), Japanese Emperor Era Calendar, Korean Tangun Era Calendar, Taiwan Era calendar, and Thai calendar. The addition of references to standards for or definitions of the following calendars to DIS 29500: Gregorian (localized) calendar, Gregorian Arabic Calendar, Gregorian Middle East French Calendar, Gregorian (U.S.) calendar, Gregorian Transliterated English calendar, Gregorian Transliterated French Calendar, Hebrew (Lunar) calendar, Hijri (Arabic Lunar Calendar), Japanese Emperor Era Calendar, Korean Tangun Era Calendar, Taiwan Era calendar, and Thai calendar.  
US Part 1, 1. Scope   te Scope: The scope statement of DIS 29500 has caused much confusion due to its lack of specificity. Moreover, a clearer scope statement could demonstrate that DIS 29500 is not concerned with the same activities as ISO/IEC 26300. As stated, the scope statement is inaccurate and misleading. Break DIS 29500 up into a true multi-part standard, in which case, each part has its own scope, definitions, conformance, and so on. For example, there might be separate parts for OPC, WordprocessingML, SpreadsheetML, PresentationML, DrawingML, and so on. (See Directives Part 2, §5.1.1.) During the process of refactoring into parts, please also consider conformance at the subpart level.

See Weir #2-002. If the multi-part approach is not used, have the OPC spec contain a note that WordprocessingML, SpreadsheetML, and PresentationML place constraints on OPC usage.

 
US Part 4, various predefined functions   te Actual: The term “Actual” and “actual” are used without definition in predefined functions. For example, in 3.17.7.2 ACCRINT and 3.17.7.348 YEARFRAC. The term “Actual” appears some 80 times in predefined functions. Since this is a date calculation, it is assumed that for some date systems, the results will be undefined for some applications. The meaning of date-count bases (such as Actual, Actual/360, Actual/365, and European 30/360)  should be defined for all predefined functions and the date systems for which they are valid.  
US Part 4, 2.18.4 ST_Border (Border Styles)   te Muffins: Part 4, 2.18.4 ST_Border enumerates border styles and includes graphic images of the borders, including the “muffin” border. However, if the goal is faithful representation of legacy documents, the enumeration falls short of that goal. There is no specification of the actual graphics in SVG or other graphics language nor it is clear that the graphics in question are available for use by implementers of the proposal. We note that the images are normative. Please clarify the requirements with respect to scaling, rotation, treatment in corners, etc. Consider providing these images in some standard graphics language form.  
US Part 4, 2.18.85 ST_Shd (Shading Patterns)   te Shading: Part 4, 2.18.85 ST_Shd enumerates shading patterns and includes graphic images of the shadings. However, if the goal is faithful representation of legacy documents, the enumeration falls short of that goal. There is no specification of the actual shadings in SVG or other graphics language nor it is clear that the shadings in question are available for use by implementers of the proposal. We note that the images are normative. Please clarify the requirements with respect to scaling, rotation, treatment in corners, etc. Consider providing these images in some standard graphics language form.  
US Part 4, Section 2.15.1.28 - te This says that document protection “shall be enforced”. “Shall” indicates required behavior. But then a few sentences later it says that document protection “may be ignored”. Strike the sentence on lines 10-11 “This protection is not intended as a security feature and may be ignored.”  
US Part 4, Section 2.15.1.28 - te A hash algorithm is provided, likely based on a legacy algorithm used in Word. 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, ISO/IEC 10118-3:2004 compliant hash algorithm as the default, such as SHA-256. Legacy hash algorithms should be supported via the described extension mechanism.  
US 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. 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.  
US Part 4, Section 2.15.1.28 line 16 te What if the entered password is shorter than 15 characters? Do we truncate to the actual length? Or fill with 0's? Or something else? Clarify this processing step.  
US Part 4, Section 2.15.1.28 pg 1159, lines 6-9 te The described processing steps are ambiguous. In particular SHR and SHL give different results on different machines and with signed and unsigned values Describe the hash algorithm in a platform independent manner.  
US 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. Loosen the declared type to an xsd:string to allow applications to provide their own classifications.  
US Part 4, Section 2.15.1.86 - te This element uses integers to specify a style display filter. A better practice would be to use self-describing string values. Rewrite this subclause to express the feature using XML constructs rather than integers.  
US Part 4, Section 2.15.1.87 - te This element uses integers to specify style display sorting parameters.  A better practice would be to use self-describing string values. Rewrite this subclause to express the feature using XML constructs rather than integers.  
US 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.  
US Part 4, Section 2.15.3.26 - te This is the “footnoteLayoutLikeWW8” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. This compatibility setting should be expressed by the application using the application-defined extension mechanism defined in Part 5, §11.  
US Part 4, Section 2.15.3.31 - te This is the “lineWrapLikeWord6” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. This compatibility setting should be expressed by the application using the application-defined extension mechanism defined in Part 5, §11.  
US Part 4, Section 2.15.3.32 - te This is the “mwSmallCaps” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. This compatibility setting should be expressed by the application using the application-defined extension mechanism defined in Part 5, §11.  
US Part 4, Section 2.15.3.41 - te This is the “shapeLayoutLikeWW8” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. This compatibility setting should be expressed by the application using the application-defined extension mechanism defined in Part 5, §11.  
US Part 4, Section 2.15.3.51 - te This is the “suppressTopSpacingWP” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. This compatibility setting should be expressed by the application using the application-defined extension mechanism defined in Part 5, §11.  
US 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 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 This compatibility setting should be expressed by the application using the application-defined extension mechanism defined in Part 5, §11.  
US Part 4, Section 2.15.3.54 - te This is the “truncateFontHeightsLikeWP6” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. This compatibility setting should be expressed by the application using the application-defined extension mechanism defined in Part 5, §11.  
US Part 4, Section 2.15.3.6 - te This is the “autoSpaceLikeWord95” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. This compatibility setting should be expressed by the application using the application-defined extension mechanism defined in Part 5, §11.  
US Part 4, Section 2.15.3.63 - te This is the “useWord2002TableStyleRules” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior.Define the intended behavior.Part 4, Section 2.15.3.64-teThis is the “useWord97LineBreakRules” This compatibility setting should be expressed by the application using the application-defined extension mechanism defined in Part 5, §11.  
US Part 4, Section 2.15.3.64 - te This is the “useWord97LineBreakRules” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. This compatibility setting should be expressed by the application using the application-defined extension mechanism defined in Part 5, §11.  
US Part 4, Section 2.15.3.65 - te This is the “ wpJustification” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. This compatibility setting should be expressed by the application using the application-defined extension mechanism defined in Part 5, §11.  
US Part 4, Section 2.15.3.66 - te This is the “wpSpaceWidth” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. This compatibility setting should be expressed by the application using the application-defined extension mechanism defined in Part 5, §11.  
US 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. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
US Part 4, Section 2.18.4 - te The artwork provided here is of poor quality providing neither intended scale, spacing, color depth, etc. A small example diagram is an insufficient definition. For example, are the dimensions of the borders absolute? Or do they scale with page size? Also, some of the images, such as 'apples' or 'balloons3Colors' show copying artifacts, where extraneous lines or blotches appear. We note that the images are normative. Please clarify the requirements with respect to scaling, rotation, treatment in corners, etc. Consider providing these images in some standard graphics language form.  
US 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. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
US 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. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters. Noting that this is the third such instance, suggest all XSD hex binary measured lengths be checked.  
US Part 4, Section 2.18.66   te §2.18.66, is lacking sufficient detail to allow interoperability.

Examples of types that need a more detailed description.

  • “decimalEnclosedFullstop” does not show enclosed characters and so contradicts the normative text.
  • “decimalFullwidth”, etc. There are several mentions of double-byte and single-byte Arabic numbering schemes. Since the conformance clause for OOXML requires the use of Unicode in UTF8 or UTF16 encodings, there should be no markup in other text encodings.
  • “lowerLetter”, etc. 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.
  • numberInDash”, etc. 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.
Either include the entire definition in the standard, or provide a proper external reference. Recommend a review of this whole subclause in this context.  
US Part 1, Section 2   te The text currently reads, “Unless documented otherwise, any feature shall be implemented as specified by the normative text describing that feature in this Standard.”  This is open-ended since it does not say where “otherwise” something may be documented.  Presumably a feature should be implemented exactly as specified by the normative text, period.  Isn’t that the reason for having normative text? Either remove this sentence or clarify how or where something “documented otherwise” can change how something specified in the normative text.  
US general   te The term "part" is used inconsistently.  In one sense it means "a portion of an ISO/IEC standard", in another sense it means "a collection of clauses within a document", and a third sense is "a unit of data".  The concept of "part" (the third sense) should be clearly defined and, possibly, a different word than "part" should be used to designate this third sense. Add definition for third sense of "part".  Make clear which sense of "part" is implied.  Possibly, use a term other than "part" for the third sense, e.g., "instance part".  
US P1-8.3   te The term "root element" is used many times throughout the standard but not defined. Define the term "root element".  
US P1-9.2   te It is unclear what requirements are implied upon the data with the statement

        For explicit relationships, the id in the source XML links to a relationship item with a direct explicit reference to the target. For implicit relationships, the relationship item is implied by the containing tag (e.g., footnote) and the id in the source XML is used to locate the correct element within the implied target.

In other words, what does "... links to ..." imply in terms of requirements?

Clarify text.  
US P1-10   te What does "Any requirement not mentioned here is inherited from the Markup Compatibility and Extensibility specification" mean in terms of requirements?  What does "inherited" mean?  What is the scope of "inheritance", e.g., do all provisions from Markup Compatibiltiy and Accessibility apply?  Regardless, the wording should be clearer such that readers can precisely interpret this statement. Clarify text.  
US P1-10.1.1   te What does "round-tripped" mean? It should be defined.  
US P1-10.1.1   te What does "hint" mean? It should be defined.  
US P1-11   te The terms and definitions are spread throughout the document. Consider moving the glossary to the Definition clause.  Possibly, a thematic ordering (as specified by ISO 10241) could be used to organize the Definitions clause.  
US P1-11.3.2   te The concept of "content type" has not been defined.  Without this definition, it is impossible to understand what these provisions mean. Move/Add to Definitions clause.  
US P1-11.3.2   te The concept of "root namespace" has not been defined.  Without this definition, it is impossible to understand what these provisions mean. Move/Add to Definitions clause.  
US P1-11.3.2   te The concept of "source relationship" has not been defined.  Without this definition, it is impossible to understand what these provisions mean. Move/Add to Definitions clause.  
US P1-11.3.2   te The concept of "comments" has not been defined.  Presumably, the definition of "comments" is different than the definition of "comments" in ISO/IEC 2382. Move/Add to Definitions clause.  
US P1-12.3.22   te The concept of "real-time data formula" is not defined. Define this term in the appropriate place.  
US P1-12.3.24   te In the statement "A Worksheet part is permitted to contain implicit relationships to the following parts defined by this Standard" it is unclear what "implicit relationship" means. Move/Add "implicit relationship" to Definitions clause.  
US P1-12.3.24   te In the statement "A Worksheet part is permitted to contain explicit relationships to the following parts defined by this Standard:" it is unclear what "explicit relationship" means. Move/Add "explicit relationship" to Definitions clause.  
US Part 1, 11.3.1   te Alternative Format Import Part: This section of DIS 29500 requires both consumption and emission of legacy text in equivalent WordProcessingML format. However, DIS 29500 fails to define a mapping from legacy formats sufficient to enable either the consumption or emission of such texts in WordprocessingML format. That DIS 29500 be amended to include the mappings from binary formats sufficient to enable conformance to the mandatory requirements of Part 1, 11.3.1.  
US Part 4, 6 VML Reference Material (and other references to VML)   te VML: VML is a legacy markup language that is deprecated in DIS 29500. As a markup language VML is clearly out of scope for DIS 29500 which is a representation of a legacy binary format using XML. VML and all references to it should be stricken from DIS 29500.  
US Part 4, 5 DrawingML Reference Material (and other references to DrawingML)   te DrawingML: DrawingML is a markup language that is defined in DIS 29500. As a markup language DrawingML is clearly out of scope for DIS 29500 which is a representation of a legacy binary format using XML. DrawingML and all references to it should be stricken from DIS 29500.  
US Part 2 Open Packaging Conventions   te Open Packaging Conventions: The Open Packaging Conventions (herein OPC) is a mechanism to define relationships between parts of documents using XML. Such capabilities were not present in the pre-existing binary format for which DIS 29500 specifies an XML representation and as such is clearly out of scope for DIS 29500. OPC and all references to it should be stricken from DIS 29500.  
US Part 2, Section 3. Definitions page 4, line 20 te This definition of 'package model' is not compatible with the prior definition given in Part 2, Section 1. Scope, page 1, line 5. Define 'package model' in unambiguous terms and use the resulting definition consistently throughout the OOXML text.  
US Part 4, Section 2.3.2.8 page 178 te It is desired to have improved interoperability between ODF and OOXML. However, OOXML's "vert" attribute only allows text to be rotated 270 degrees, whereas ODF's equivalent allows text rotation by 90 or 270 degrees. Include ability to specify 90 degree text rotation in addition to existing 270 degree rotation.  
US Part 4, Section 2.4.46 page 421 te It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the ability to specify a multi-row header that repeats across pages, where ODF does. Include in this section the ability to specify that the first N rows of a table can be selected as a header.  
US Part 4, Section 2.3.2.1 page 160 te It is desired to have improved interoperability between ODF and OOXML. However, OOXML text runs only support two font weights, bold or normal, where ODF supports the fuller range of font weights from XSL-FO Include support for additional font weights, 100, 200, 300, 400, 500,600. 700, 800 and 900.  
US 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.  
US Part 4, Section 2.16.4.3 page 1501, line 0 te The definition for BATHTEXT references 'the given Thai format', which makes no sense in the context of that definition. What “given Thai format”? Clarify the definition of 'BATHTEXT'.  
US Part 4, Section 2.16.5.33 - te This field says that it merely retrieves the picture contained in the named document. Is nothing else to be done with the picture? For example, should it be displayed? Define what is to be done with the picture once it is retrieved.  
US 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.  
US 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.  
US Part 4, Section 2.16.5.34 - te This does not define how a document is named. Is it by a URI? By a local file system path? Either? The example given has a DOS file path, a construct which is not portable. Define how documents are named.  
US 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.  
US 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. Provide a proper external normative reference for the XSLT and Xpath versions which are allowed here.  
US Part 4, Section 2.16.5.5 page 1512, lines 11-12 te According to the text, the AUTONUM field is deprecated. A new standard should not contain deprecated parts. Remove all references to AUTONUM from the OOXML text.  
US Part 4, Section 2.16.5.77 - te The example that illustrates USERINITIALS section instead shoes USERNAME. Correct the example..  
US Part 4, Section 2.18.4 - te No mechanism for expanding the set of art borders is provided. Since the specified art borders are heavily Western-oriented, it would be good to provide a way for an application to supplement these styles with graphics that provide more regional flavor. Provide an interoperable extensibility mechanism for a document author or application to specify their own art border graphics.  
US Part 4, Section 2.18.51 - te The use of 255 enumerated language codes, in addition to ISO 639-1 codes, adds no expressive value and only increases the work required of any application that would process an OOXML document. Drop the use of the redundant ST_LangCode  
US Part 4, Section 2.18.52 - te This type is defined as containing, “a two digit hexadecimal language code”. It is fruther stated that, “This simple type's contents must have a length of exactly 2 characters”. However, two hex digits can count up to 255 and the values enumerated in this clause go far beyond that. Reconcile the description of the type with the enumerated values.  
US Part 4, Section 2.18.66 - te The formatting system described here is not comprehensive, lacking, for example, support for Armenian, Tamil, Greek alphabetic, Ethiopic and Khmer numerations, all in use today, as well as the various historical systems still used by scholars. Use a more flexible, extensible, generative approach to numeration, such as that used by the W3C's XSLT standard in their xsl:number support  
US 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.  
US Part 4, Section 2.18.72 - te No definition is provided for a “Panose-1 classification” of a font. Provide a proper external normative reference for this term.  
US 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. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
US Part 4, Section 2.18.85 - te The fill patterns lack definitions. The illustrations given are insufficient. An application needs to know what in these illustrations are required behaviors and what are not. For example, is the exact dithering pattern used in the illustration required? Provide full normative definitions for these graphical elements.  
US 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. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
US Part 4, Section 2.2.1 page 28, line 0 te The reference to the urn:schemas-microsoft-com:vml namespace references VML, which is considered as deprecated (Part 4, page 4343, lines 11&12). A new standard should not contain deprecated parts. Remove all references to VML from the OOXML text, hence remove the reference to the urn:schemas-microsoft-com:vml namespace here.  
US Part 4, Section 2.2.1 page 28, line 0 te Child elements of background are described using deprecated features only. Accordingly, the background element should either be described in terms of current OOXML elements or deprecated. Describe the background element in terms of non-deprecated elements or remove it.  
US Part 4, Section 2.2.1 page 28, line 1 te The sentence 'or auto to allow aconsumer to automatically determine the background color as appropriate.' does not define the appropriate behavior of the consumer, whereas the definition of the corresponding simple type, found in Part 4, page 1737, explicitly states that 'This value shall be used to specify an automatically determined color value, the meaning of which is interpreted based on the context of the parent XML element.' Define the characteristics of the auto value for the color attribute of the background element properly.  
US Part 4, Section 2.2.1 page 29, line 0 te There are several instances of the word 'border' that are meaningless in this context (the text is supposed to describe the 'background' element at that location and no “border” has been defined). Clarify which border the text refers to (if any notion of border must be introduced here) or else rewrite the text so that it makes sense.  
US Part 4, Section 2.2.1 background (Document Background) page 27, lines 8&21 te Contradicting use of accent3 and accent5 – the text says one thing, but the example says another. Fix the contradiction.  
US Part 4, Section 2.3.1.8 - te This element uses a bitmask to specify various paragraph conditional formatting properties.. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.  
US 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  
US Part 4, Section 2.4.51 - te This element uses a bitmask to specify various table style formatting properties.. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.  
US Part 4, Section 2.4.52 - te This element uses a bitmask to specify various table style formatting exceptions. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.  
US Part 4, Section 2.4.7 - te This element uses a bitmask to specify various table cell formatting properties.. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.  
US Part 4, Section 2.4.8 - te This element uses a bitmasks to specify various table row formatting properties.. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.  
US Part 4, Section 2.8.2.16 - te This element uses a set of bitmasks to specify which code pages a given font supports. The use of bitmasks rather than an XML Schema derived type makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. One of the advantages of XML is that we don't need to encode data like this any more. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.  
US Part 4, Section 3.17.4.1 - te The restriction to only two date bases is arbitrary and based only on one vendor's applications. There are other reasonable values for date bases, including earlier ones for historical dates. Most SQL databases, which frequently exchange data with spreadsheets, support a much greater range of dates. Allow a range of vendor-declared date bases, or explicitly allow negative date serial values to express dates prior to 1900  
US Part 4, Section 3.17.4.1 - te The mandated incorrect date calculations for 1900 in the 1900-based date basis is unacceptable. 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. If needed for legacy reasons with legacy Excel documents, then introduce an additional vendor-specific tag such as “doWrongDateCalculationsLikeExcel” or similar. This is the approach used elsewhere in OOXML for legacy Word features  
US Part 4, Section 3.17.4.1 page 2522, lines 14-18 te The text proposes a dual date base system. There is no clear advantage to having two slightly different systems, and this brings significant costs and confusion, as illustrated by the need to specify a default base system, etc. Choose and keep a single date system.  
US Part 4, Section 3.17.4.1 page 2522, lines 16&18 te The documented upper limits for serial date times match 9999-12-31 00:00:00, which is most probably not what was intended. The expected upper limits would match 9999-12-31 23:59:59. Clarify the upper limits.  
US Part 4, Section 3.17.7.341 - te As written this function mandates an incorrect calculation for day of week for certain dates in the year 1900. An ISO standard should not be mandating incorrect values for the well-established Gregorian Calendar. To do so will only lead to confusion, poor interoperability and perpetuation of errors. Remove the text that defines behavior that results in incorrect date calculations.  
US 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. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
US 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 or 4 characters. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
US 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. 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.  
US 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 protection feature useless. This is unacceptable. Remedy so password hashes can be calculated on any Unicode password.  
US 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.  
US 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.  
US Part 4, Section 3.3.1.61 - te The pageSize attribute allows a set of enumerated values which does not encompass all of the page size values permitted by ISO 216, ANSI Y14.1 and similar DIN and JIS standards. Rather than trying to maintain a paper size registry, a more flexible approach would be to simply record the dimensions of the paper size selected.  
US 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.  
US Part 4, Section 3.3.1.69 - te The securityDescriptor attribute, “definesuser accounts who may edit this range without providing a password to access the range”. It is a string. But no information is given as to what user accounts are referred to here, or what the delimiter is. Are these comma-delimited local machine user accounts? Or semi-colon delimited LDAP DN's? There will be no interoperability if this is not defined. Fully define this attribute.  
US 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, FIPS-180 compliant hash algorithm as the default. Legacy hash algorithms should be supported via the described extension mechanism.  
US Part 4, Section 5.1.12.28 - te This type is used in only two places, 5.1.2.2.32 and 5.1.2.2.33, in both cases to represent an RGB color value. Since you already have defined a ST_HexColorRGB type that should be used. Use the ST_HexColorRGB type and remove ST_HexBinary3  
US 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. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
US Part 4, Section 5.1.12.37 - te No definition is provided for a “Panose setting of a font”. Provide a proper external normative reference for this term.  
US Part 4, Section 5.1.12.37 - te The Panose value is said to be used, “so that generating applications using this Office Open XML Standard may determine the closest font type if necessary”. However, no font distance metric or font matching heuristic is described. Describe the intended font matching procedure.  
US Part 4, Section 5.1.12.37 - te Length is said to be “exactly 10 characters”. This is inconsistent with the schema fragme Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
US Part 4, Section 5.1.3.2 - te No mention is made of what audio formats or codecs are permitted. An interoperable set of formats should be specified.  
US 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.  
US Part 4, Section 6 - te OOXML specifies here a markup language called Vector Markup Language (VML) which, in addition to DrawingML, specifies a vocabulary for describing graphical objects. Section 6.1 says, “The DrawingML format is a newer and richer format created with the goal of eventually replacing any uses of VML in the Office Open XML formats. 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” The need to support VML by OOXML consumers, in addition to DrawingML, would come at great implementation expense (the VML specification is over 600 pages) , would disadvantage all vendors but Microsoft, and would hurt interoperability. Remove VML from OOXML. Vendors who have access to the legacy binary format documentation, such as Microsoft, are free to convert the VML to the “newer and richer” DrawingML at the same time they convert the document to OOXML.  
US Part 4, Section 6.1 page 4343, line 8 te The reference to 'millions of documents' is an unsupported assertion. Furthermore, it is irrelevant in the context of a standard proposal. Remove the marketing fluff from the text.  
US 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.  
US 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.  
US Part 4, Section 6.1.2.7 page 4444, “tableproperties” te This element uses a bitmask to specify VML table properties. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.  
US 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.  
US 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.  
US Part 4, Section 6.4.3.1 - te The allowed values of this enumeration, EMF, WMF, etc., are Windows-specific formats. No allowance seems to have been made for use by other operating systems. For example, in Linux images are typically copied on the clipboard in an open standard format like PNG. Several options here, but the desire is to allow cross platform interoperability.  
US Part 4, Section 7.1 - te This is the specification of Office Open Math Markup Language, a specialized XML vocabulary for the describing the layout of mathematical equations. This solves the same problem as MathML, a long-established W3C standard and an ongoing activity in the W3C. Since the equation editing feature of Word was entirely rewritten in Word 2007, there doesn't not seem to be the argument that an additional equation language must be introduced for the sake of legacy documents. 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.  
US Part 4, Section 7.4.2.4 - te The presence of non-XML characters, escaped, or not escaped in an OOXML document, is contrary to interoperability of XML and XML-based tools. The W3C's Internationalization Activity confirms this interpretation, saying “Control codes should be replaced with appropriate markup. Since XML provides a standard way of encoding structured data, representing control codes other than as markup would undo the actual advantages of using XML. Use of control codes in HTML and XHTML is never appropriate, since these markup languages are for representing text, not data.” Remove the bstr type from OOXML  
US Part 4, Section 7.4.2.4 - te This defines a new XML string type which allows the inclusion via an escape mechanism of Unicode characters which are otherwise impermissible in XML documents. However, any escape mechanism must also specify a mechanism for “escaping the escape”. So, how does one represent the literal example given in 7.4.2.4 in a bstr? Complete the definition of the escape mechanism.  
US 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.  
US 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.  
US Part 4, Section 7.4.2.5 - te This element defines values for use on Windows and Macintosh platforms, but not for Linux or any other operating system. Several options here, but the desire is to allow cross platform interoperability.  
US Part 4, Section 7.4.2.5 - te Even within a single platform, there is not enough information given to achieve interoperability. For example, what are the allowed values and meanings for a “built-in Windows clipboard format value”? Specify this so interoperability may be achieved.  
US 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.  
US Part 4, Section 3.17.3 “#DIV/0!” te The “note” for this error value appears to define required behavior, not informative remarks Make the contents of the note be part of the main text, not as a note.  
US 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.  
US 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”.  
US 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”.  
US 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.  
US 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  
US 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.  
US Part 4, Section 3.17.7.11 ASC te This function converts a DBCS string to “half-width (single byte)” characters. But the mapping from DBCS to single byte. is undefined. What is intended here? Truncation? Conversion into nearest single byte character set? Provide a fuller definition of this function.  
US Part 4, Section 3.17.7.12 ASIN te It is not indicated whether the returned value shall be in radians or degrees Specify the angular units that should returned  
US Part 4, Section 3.17.7.14 ATAN te It is not indicated whether the returned value shall be in radians or degrees Specify the angular units that should returned  
US Part 4, Section 3.17.7.15 ATAN2 te It is not indicated whether the returned value shall be in radians or degrees Specify the angular units that should returned  
US 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.  
US 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.  
US 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.  
US 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.  
US 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.  
US 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  
US 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  
US 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  
US 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  
US 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.  
US 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  
US Part 4, Section 3.17.7.74 DATE te The definition of date normalization is rather loose. I think you want to say something like this; “if month is greater than 12, then month-12 shall be added to the first month in the year specified.”, etc. The problem with how it is stated is that “that” does not refer to anything in “that number of months”. Clarify the definition of date normalization.  
US 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.  
US 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.  
US Part 4, Section 3.17.7.91 DISC te 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)  
US 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  
US 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.  
US Part 4, Section 3.17.7.101 DURATION te 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)  
US Part 4, Section 3.17 throughout te The mathematical formula given in many places borders on unreadable and compares very poorly with the clarify of the rest of the text and most other images. Provide better quality mathematical formula.  
US Part 4, Section 3.17.7.111 EXACT te String comparisons in an international setting are typically described as either lexical comparisons where the strings are compared character by character for identity, and by collation comparisons where equivalent characters are considered identical. This function does not say which method it uses. Clarify what defines two strings as having identical content.  
US part 4, Section 3.17.7.118 FIND te Similar issue to EXACT. Is this a lexical comparison or collation-based? Clarify the basis for finding substrings  
US Part 4, Section 3.17.7.119 FINDB te Similar issue to EXACT. Is this a lexical comparison or collation-based? Clarify the basis for finding substrings  
US Part 4, Section 3.17.7.120 FINV te This function says, “FINV 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.  
US Part 4, Section 3.17.7.123 FIXED te The rounding algorithm is not specified. How for example, do we calculate FIXED(0.5,0)? State what the rounding conventions are.  
US Part 4, Section 3.17.7.125 FORCAST 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  
US Part 4, Section 3.17.7.131 GAMMAINV te This function says, “GAMMAINV 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.  
US Part 4, Section 3.17.7.143 HOUR te This function returns the hour given a date/time value. However, the text says, “The returned value shall be in the range 0–59.” Surely the hour should be in the range 0-23? Correct the text  
US Part 4, Section 3.17.7.144 HYPERLINK te The definition says that an allowed format for the link-location parameter is a “universal naming convention (UNC) path on a server”, though this term is not defined. Provide a normative definition or reference for a UNC path.  
US Part 4, Section 3.17.7.169 INTERCEPT 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  
US Part 4, Section 3.17.7.172 IRR te This text says, “IRR uses an iterative calculation 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.  
US Part 4, Section 3.17.7.186 KURT te Definition is incomplete. Formulas don't stand for themselves. You need to connect the notation to the function arguments. So, as stated, “where s is the sample standard deviation”, but it should be followed by, “and n is the number of data points in the range, and X-bar is the sample mean” Provide the complete definition.  
US Part 4, Section 3.17.7.186 LINEST 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  
US 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.  
US Part 4, Section 3.17.7.206 MDURATION te 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)  
US 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.  
US 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.  
US 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.  
US 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.  
US 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  
US 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  
US 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  
US 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  
US 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  
US 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  
US 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  
US 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  
US 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  
US 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  
US 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  
US 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  
US 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  
US 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  
US 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  
US 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.  
US 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.  
US Part 4, Section 3.17 Formula and following   te FormulaString: String is not defined in such a way as to enable a meaningful definition of formulas. Part 4, Section 3.17.2.6 reads in part: “A text value or constant represents arbitrary text, and can have any value defined for string-constant (§3.17.2.1).

The term "string" is used as a generic name for any expression of type text.” But Part 4, Section 3.17.2.1 says (in part):

string-constant:

    " [ string-chars ] "

string-chars

    string-char

string-chars string-char

    string-char

    ""

   any character except "

Defining string operations in the absence of a definition of string is meaningless.

“String” should be defined for use in the definition of formulas and once defined, the formulas specified that rely upon that definition must be reviewed.  
US Part 4, Section 3.18.95   te ST_XmlDataType: ST_XmlDataType reports that the values listed are restrictions on XML Schema string datatype. That is incorrect. The datatypes: Boolean, decimal, float, double, duration, dateTime, time, date, gYearMonth, gYear, gMonthDay, gDay, gMonth, hexBinary, base64Binary, anyURI, Qname, and NOTATION, are all primitive datatypes and not restrictions on XML Schema string. The text should be amended to indicate that the values (at least some of them) are primitive XML Schema datatypes and to report others (if appropriate) as restrictions on XML Schema string. Moreover, all datatypes in DIS 29500 should be evaluated for their correctness and what affect, if any, that correcting datatypes will have on definitions in other parts of DIS 29500.  
US Part 4, Section 3.18.95 ST_XmlDataType (XML Data Types)   te XMLDataTypes: The URIs reported for the data types in this section are incomplete. For example: http://www.3.org/2001/XMLSchema#anyType is the correct URI for anyType, not  http://www.w3.org/2001/XMLSchema. The correct URIs for datatypes should be inserted in this section. Moreover, all references should be proofed for correctness and conformance to proper methods of citation.  
US Part 4   te There are 263 uses of invalid xsd:boolean attribute values: For example, take part 4, 3.10.1.90 "sharedItems.  In the definition of the attributes containsBlank, containsDate, it says:

"Specifies a boolean value that indicates whether this field contains a blank value.

A value of on, 1, or true indicates this field contains one or more blank values.

A value of off, 0, or false indicates this field does not contain blank values.

The possible values for this attribute are defined by the XML Schema boolean datatype."

However, XML Schema 3.2.2.1 (http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#boolean) defines allowed lexical value space for xsd:boolean as:

"An instance of a datatype that is defined as boolean can have the following legal literals {true, false, 1, 0} "

"On" and "Off" are not allowed values.  

A search of Part 4 indicates 262 other instances of this problem, all in SpreadsheetML and DrawingML.

This could be fixed by amending the text to remove the "on" and "off" options or by changing the schema to refer to the ST_OnOff type defined in 2.18.67, which does allow this set of values.  
US Part 4, Section 6.4.2.6 AutoPict te The text says, “This element specifies whether the object's size is formatted automatically by the application. If this element is specified without a value, it is assumed to be true. This is a general-use element for objects that use an image representation, such as OLE objects, Embedded controls, cameras and signature lines.” 

The objects listed after the words "such as ..." must be interpreted as an exhaustive or partial list ? What ST_ObjectType's object types (6.4.3.2) correspond to "OLE objects", "Embedded controls" or "signature lines"? 

Define the applicable objects for this element according to the ST_ObjectType type.  
US Part 4, Section 6.4.2.7 AutoScale te The text reads, “This element specifies whether the object's font is automatically scaled by the application when the object is resized. If this element is specified without a value, it is assumed to be true. This element is used for attached text.” 

“attached text” is not one of the allowed values of the ST_ObjectType type.

Define the applicable objects for this element according to the ST_ObjectType type.  
US Part 4, Section 6.4.27 FmlaMacro te The text reads, “This element specifies the custom function associated with the object” But no objects are listed for this element. List what ST_ObjectType objects this element can be applied to.  
US Part 4, Section 6.4.2.4 AutoFill te The text says, “This element specifies that the object is an AutoFill object. If this element is specified without a value, it is assumed to be true. This is a general-use element.” 

However, nowhere in the spec is an “AutoFill object” defined. 

Define the behaviour of an “AutoFill object”  
US Part 4, Section 6.4.2.5 AutoLine te The text says, “This element specifies that the object is an AutoLine object. If this element is specified without a value, it is assumed to be true. This is a general-use element.” 

However, nowhere in the spec is an “AutoLine object” defined.

Define the behaviour of an “AutoLine” object”  
US Part 4, Section 6.4.2.8 Camera te The text reads, “"This element specifies that the object is a camera object. A camera object shows a live view of another part of the spreadsheet. If this element is specified without a value, it is assumed to be true. This element is used for cameras."  

However, a “camera” is not defined in this context, nor its behavior.

Define the behaviour of this “camera object”.  
US Part 4, Section 3.17.7.249 PI te The provided example contradicts the description, since it displays 10 significant digits in its fractional part instead of the (minimum) 15 significant digits which is stated as a requirement. Fix the example or the text, so this contradiction is resolved.  
US Part 4, Section 3.17.2.1 Constants te The syntax of constants is defined using an unspecified notation, that appears to borrow some characteristics of Backus-Naur Form for grammar productions, some notations from popular ways of specifying command line applications options, etc., all without formally defining the notation used.  

Note that other parts of the syntax for formulas similarly lack a proper format definition.  The reference to the “constants” section is one example.

Either adopt a formal lexical-syntactic notation by reference (for example ISO 14977:1996 EBNF), or explicitly define your own.  
US Part 4, Section 3.17.2   te The reference to the definition of the space operator is broken ('§0'). Fix the reference  
US Part 4, Section 3.17.2   te The reference to the definition of operators is broken ('§0'). Fix the reference  
US Part 4, Section 2.16.1 Syntax te The production rule for field-switch-character is defined as: 

field-switch-character:

!

one or two Latin letters” 

However, “Latin letters” is not defined in this specification.  Are we to take this literally as only allowing the letters used in Latin, i.e., capital letters A-Z excluding J, U and W?  Or is meant the ISO 8859-1, the Latin-1 character set?  Or is something else meant?

Provide a precise definition for this production rule.  
US P1-1.1   te In the Scope statement, it says: "This Standard defines ... vocabularies ...".  This is incorrect use of the term "vocabulary".  The proper term is "value domain" (as defined by ISO/IEC 11179). Change "vocabularies" => "value domain", and take definition of "value domain" from ISO/IEC 11179.  
US P1-2.6   te This subclause should be re-titled "Interoperability Provisions" and should clearly state what provisions (shall, should, may) are implied.    
US P1-4   te The term "extension" only includes XML kinds of extensions and not other kinds of extensions, such as additional permissible values (not necessarily an XML issue) and additional value meanings (e.g., enhancing the meaning of an existing feature). The term extension should be broadened:

extension: a feature that is specified outside this International Standard

 
US Part 4, Section 3.2.29 -   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, FIPS-180 compliant hash algorithm as the default. Legacy hash algorithms should be supported via the described extension mechanism.  
US 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. Correct the terminology to correctly reflect the status of DIS 29500.  
US Part 1, Section 2.3 “What this Standard Specifies” line 14 ed Are additional syntactic constraints only normative when the cannot be feasibly expressed in the schema language? Who judges this? The use of the word “whenever” is ambiguous. Is this a condition under which such statements are normative or an explanation of why such statements exist? What may be meant is that the additional syntactic constraints are normative, period. Clarify this sentence, perhaps by omitting the editorial explanation about why such additional constraints are not in the schema.  
US Part 1, Section 2.6 “Interoperability Guidelines” lines 33-34 ed Is this recommending that a non-public, internal-only, work-for-hire application author create “publicly available documentation” on what subset of the standard it supports? The business relationship between the software author and his customer should not be a concern of this standard. Change to read, “a software application should be accompanied by documentation...”  
US Part 1, Section 2.3 “What this Standard Specifies” line 16 ed The use of the word “element” is ambiguous. Is this to mean XML elements (but not attributes, character content, etc.)? Or does this mean an element of the Standard, in the usage of ISO Directives, Part 2? Clarify the use of the word “element” perhaps by saying “XML element” if that is what is meant.  
US Part 1, Section 2.6 “Interoperability Guidelines” - ed The use of the word “element” is ambiguous. Is this to mean XML elements (but not attributes, character content, etc.)? Or does this mean an element of the Standard, in the usage of ISO Directives, Part 2? Clarify the use of the word “element” perhaps by saying “XML element” if that is what is meant.  
US Part 1, Section 2.6 “Interoperability Guidelines” line 15 ed Obviously the Standard anticipates such behavior since it explicitly contains the present example describing this behavior and calls it conforming. Perhaps it is meant to say, “...this Standard does not recommend this behavior”.  
US Part 1, Section 4 “Definitions” behavior, unspecified ed This definition doesn't work, since the Standard, in defining compliance in Section 2, says that “compliance is purely syntactic”. So no behaviors are required. Therefore, by this definition, all behaviors are unspecified? Surely this is not what is meant. Clarify this definition. Perhaps it is meant to say, “Behavior for which this Standard does not make a recommendation”?  
US Part 1, Section 4 “Definitions” Office Open XML Document ed This definition doesn't hold together. Are these two different definitions? Or two clause of which either will define the term? Or both together define the term? Clarify the definition  
US Part 1, Section 9.1.7 line 10 ed The naming convention giving is incorrect. H is a hexadecimal digit, not a hexadecimal value. Follow correct usage pattern as established earlier in 9.1.1.  
US Part 1, Section 9.1.9 line 25 ed Incorrect subject. A producer qua producer does not round trip. Should say, “Conforming producers that are also consumers should...”  
US Part 1, Section 9.2 page 18, line 8 ed Extra period following “explicit.” Remove extraneous punctuation  
US Part 1, Section 15.2.8 - ed The examples given are rendered useless by the predominance of the VML in the markup. Make a more succinct and clear example by concentrating on the control persistence.  
US Part 4 in its entirety   ed Duplication: Part 4 of DIS 29500 repeats the definitions of attributes throughout the text. This greatly adds to the length of the text at the expense of readability of the document as a whole. Part 4 of DIS 29500 should be edited to include only one definition of any attribute and following occurrences should have a reference to the initial definition.  
US Throughout DIS 29500   ed Confusing Notes and Examples: There appears to be no consistent editorial principle applied to distinguish between notes and examples in the text. Text that looks like examples appear in notes and what are probably notes appear in examples with no distinguishable principle for the use of one over the other. The document should be amended to consistently and on the basis of some principle to distinguish between examples and notes.

As specified by the ISO/IEC Directives, Part 2, §6.5.1, note and example elements shall not contain requirements or any information considered indispensable for the use of the document.” That is, there should not be any normative requirements specified only in a note or example.

 
US DIS 29500   ed/te Some examples appear to be incorrect and/or inconsistent with the normative text that they are intended to illustrate. Suggest that the examples be reviewed for correctness and consistency with the normative text that they are intended to illustrate.  
US Part 2, Section 1. Scope page 1, lines 9 ed The 'well-defined naming guidelines' expression is confusing, since OOXML front matter said that 'guidance' parts of the text are meant to be informative only. Replace 'guidelines' with 'rules' since the naming patterns are normative.  
US P1   ed The definitions of "consumer" and "producer" should be moved to the Definitions clause.    
US DIS 29500   ed/te Naming DIS 29500: The current name of DIS 29500, Office Open XML is seriously misleading in several respects. First, it is not a document format based on XML but rather an XML representation of a legacy document format with particular processing semantics. Second, reference should not be made to commercial products and clearly “Office” in the title of this proposal is meant as a reference to Microsoft Office. Lastly, the proposal is no more or less open than any other ISO proposal and so “Open” is meaningless in this context. It is suggested that a new name be chosen for the proposal that reflects its goal of representing and continuing a legacy document format as represented in XML. Such a name should not carry an implied reference to a Microsoft product nor should it use the term “open.” One possible name would be: Legacy Document Formats Represented in XML. The principles developed from this effort might well prove effective for other legacy document formats that should be represented in XML.  
US Part 4, Foreword page vi, line 9 ed Explicitly references annexes that are not provided in a humanly-readable format, whereas a human-readable format is required by JTC1 Directives 8.3.5 and JTC1 Directives Annex H Annexes should be provided in a humanly readable, lined-numbered format so it can be referenced and cited. The reference to electronic form only annexes should be removed.  
US Part 4, Introduction page vii, line 8 ed An XML markup cannot be “fully compatible” with an “investment” Remove the marketing fluff  
US Part 4, Section 1. Part Overview page 1 ed The use of 'Part' for different things is confusing. Line 1 (title) it refers to Part 4 as a subpart of OOXML. Line 3 it implicitly refers to WordprocessingML, SpreadsheetML, etc. Use another word like 'subpart' when referencing WordprocessingML etc., or else use full names for the markup.  
US Part 4, Section 2.18.51 line 22 ed double quotes used incorrectly, with two sets of close quotes. XML examples should be given using straight quotes  
US Part 4, Section 6.1 page 4343, lines 4&5 ed What does 'This namespace' refer to? There is no obvious namespace in the context of that sentence. Clarify.  
US Part 4, Section 3.17.7.17 AVEDEV ed The example given is incorrect. It is a formula for calculating the number of combinations of n things taken k at a time. This does not concern absolute deviation. Provide a correct example.  
US Part 4, Section 3.17.7.17 AVEDEV ed The function description has a typo/duplication: “cells with the value 0value 0” Fix the typographical error  
US Part 4, Section 3.17.7.37 CHIINV ed 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.  
US Part 4, Section 3.17.7.78 DAY   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.  
US Part 4, Section 3.17.7.89 DEVSQ ed The function description has a typo/duplication: “cells with the value 0value 0” Fix the typographical error  
US DIS 29500   ed/te ElementNaming: DIS 29500 follows no consistent principle for the naming of elements. While it abbreviates the element for “Use Complex Script Formatting on Run” to “cs” (Part 4, section 2.3.2.6), it also has the element “customXmlMoveFromRangeStart” (Part 4, section 2.13.5.9). This is not an isolated example. In the portion of the table of contents reproduced as Annex A, there are approximately 712 element names down to Part 4, section 2.15.3.67. Out of that total, some 575 have whole words in the element names, sometimes more than one. In other words, 80% of that portion of DIS 29500 does not name elements with any consistent abbreviation principle. DIS 29500 should be edited with a consistent element naming philosophy. It can either choose to have meaningful names or semantically opaque ones but it should choose one or the other.  
US Part 4, Section 2.3.3.14 tid ed The text says, “This element specifies the language which shall be for this phonetic guide.”  This sentence is missing a verb.  Is it “used”? Insert the missing verb  
US Part 4, Section 3.17.7 Throughout ed There appears to be a production issue in the creation of the PDF version of this DIS.  Many of the mathematical formulas that define the spreadsheet functions are illegible, and all of them are of low quality.  For example,  3.17.7.24, 3.17.7.32, 3.17.7.38, etc. Provide higher resolution of the mathematical equations.  
US Part 3, Section 8.3.4.1.1   ed The graphic provided in the example is almost impossible to read, but appears to be malformed XML. Make an easy to read example (perhaps lighter background color) and make the example well-formed.  
US 3.18.95   ed All of the URL’s provided here are incorrect.  They lack the colon following “http”. Correct the URL’s  
US general   ed The first handful of clauses should be reorganized to match common ISO standards: 1. Scope, 2. Normative References, 3. Definitions, 4. Conformance. OLD => NEW

1. Scope => 1. Scope

2. Conformance => 4. Conformance

3. Normative References => 2. Normative references

4. Definitions => 3. Definitions

5. Notational conventions => Foreword (as per ISO/IEC Directives, Part 2, subclause 6.1.3, item c)

6. Acronyms and Abbreviations => add to 3. Definitions

 
US general   ed References to ISO/IEC 10646-1 should be ISO/IEC 10646:2003.    
US general   ed In general, short examples should be footnotes.

Notes should be presented according to ISO/IEC Directives, Part 2.

   

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

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

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

page of 44

ISO electronic balloting commenting template/version 2001-10


Top