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
Ecma / Part 4, 3.10.1.73 / te / Section 3.10 (part 4) - Pivot Tables - More information is needed regarding the layout of Pivot Table headers. Although the types of headers in a pivot table are described, their layout is not well defined, particularly in the context of attributes like 'gridDropZones' and discussions of 'compact mode'. / Describe header layout for pivot tables in detail, addressing at least the following issues:
• A precise definition of ‘compact mode’.
• A precise definition for the attribute ‘gridDropZones’.
• Precise definitions for all other pivot-table elements and attributes that are not well-defined in DIS 29500.
Ecma / Part 4, 3.3.1.81 / te / Currently the described behavior for the Booleans is a bit unclear. For instance, there may be confusion over whether the text 'selection of locked cells is locked' means allow or disallow / The text should be much more clear on when something is permitted. In addition, the default values should be clarified.
Ecma / Part 4, 3.17.7.34 / te / CELL: The keywords can be translated in other locales.
e.g., CELL("adresse",...) in France.
The table of acceptable keywords needs to be appended. / Provide the set of acceptable keywords.
Ecma / Part 4, 3.17.7.166 / te / INDIRECT: clarify documentation that a name can only contain a ref, not an expression. The language 'a name defined as a reference' is unclear. Ideally, it would be removed and the constraint would be implementation-specific.
e.g., INDIRECT("foo") with foo==B2 is ok, but
e.g., INDIRECT("foo") with foo==IF(A1,A2,A3) is not?
This seems like it should be marked as implementation-defined to avoid constraining things. / State that a named expression is allowed as the first argument; however, the content of the named expression has implementation-defined constraints.
Ecma / Part 4, 3.8.31 / ed / Section 3.8.31 (Part 4) - This section contains some misspellings, specifically "laoding" and "Tawian". / Correct these spelling errors.
Ecma / Part 4, 3.8.31 / te / Part 4, 3.8.31 - The formatting code "e" goes to "yyyy" in other locales, but the text states it goes to "yy". / Correct the text.
Ecma / Part 4, 3.8.30 / te / The definitions for the built in styles 5-8 are omitted from the list. / Include the definitions for built-in number styles 5-8.
Ecma / Part 4, 3.8.30 / te / Calc Number format issue: Locale specific formats
- "Some of these Ids _are_ interpreted differently, depending on the UI language of the implementing application." Is this an 'are' or a 'can be'? / Make it clear that the interpretation of these IDs is implementation-dependent. An implementation might choose to interpret them in a locale-dependent manner.
Ecma / Part 4, 3.8.30, 3.8.31 / te / Language names CHT, CHS, and others are used here in several places as qualifiers, but there is no further description for them, nor are they language names from a standard such as ISO 639. / Provide updated information sufficient to clarify the language name qualifiers.
Ecma / Part 4, 4.6.18, 4.6.24 / te / Part 4, 4.6.18, 4.6.24 - PresentationML 'transitions' are not described. Documenting a dynamic process is clearly difficult, but there needs to be at least some text characterizing the mechanics. Possibly provide a small series of still frames to describe the effect visually, or ideally an appendix of animated images to demonstrate. / For each transition, provide a series of still frames to describe the effect visually.
Ecma / Schema, shared-math / te / Possible shared-math schema error: Review the shared-math schema to see if the following from it is correct; specifically, are the references to xpath="m:annotation/m:content" and xpath="m:annotation/m:context" correct as these targets do not seem to be defined anywhere?
<xsd:complexType name="CT_OMathPara">
<xsd:sequence>
<xsd:element name="oMathParaPr" type="CT_OMathParaPr" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>Office Math Paragraph Properties</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="oMath" type="CT_OMath" minOccurs="1" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>Office Math</xsd:documentation>
</xsd:annotation>
<xsd:unique name="uniqueContentAnchorIdsInsideMath">
<xsd:selector xpath="m:annotation/m:content" />
<xsd:field xpath="@id" />
</xsd:unique>
<xsd:unique name="uniqueContextAnchorIdsInsideMath">
<xsd:selector xpath="m:annotation/m:context" />
<xsd:field xpath="@id" />
</xsd:unique>
</xsd:element>
</xsd:sequence>
</xsd:complexType> / Remove the <unique> elements from the schema.
Ecma / Schemas / te / No schemaLocation for XML namespace
OOXML XML Schemas reference xml:space as an attribute value, but don't provide a schemaLocation for the schema for the XML namespace. Although this is valid XML Schema (the schemaLocation is a hint, rather than required), it imposes an unnecessary complication on using the schema (since the schema location must be specified separately, either automatically by the validator as MSXML does, or using a catalog as most other tools do). / Include reference to xml.xsd
Alter the stylesheets (wml.xsd, shared-math.xsd) that import the xml namespace to include a schemaLocation of
Affects files: wml.xsd, shared-math.xsd"
Ecma / Schemas, Part 4, Annex A / te / Currently some of the the W3C XML schema files for part 4 make use of the xsd:import functionality to import additional XSD files that all combine to define one namespace. There are multiple import statements pointing to the different locations for each XSD file. There is some ambiguity as to whether or not this method is appropriate, and many XML parsers do not support it. As a result, many of the schema files from part 4 will not work in these parsers. / Modify the schemas that use this inclusion feature in order to enable the OpenXML schemas to be handled at least by Xerces-J and MSV. It is possible to modify the OpenXML schemas without impacting the document instances validated by the current version of the OpenXML schemas.
Ecma / Part 2, Annex B / te / The "pack" URI scheme is not yet endorsed by IETF.
Drop the "pack" URI scheme unless it is endorsed by IETF. / The “pack” URI scheme was submitted to IETF ( on August 16, 2007. It is hoped that IETF will accept and register this as it an extremely important mechanism for accessing parts from within a package. However, at the time of the BRM, in the event the “pack” URI is rejected (or not yet accepted) by IETF, “pack” URI should be removed.
Ecma / Part 2, 8.1 / te / It is desirable to support non-ASCII characters (IRIs) in part names, but the OPC supports only US-ASCII characters (only URIs) in part names. / Support IRIs for part names at the logical level.
Ecma / Part 4, 8.2.1 / te / Custom schemas can be written only in W3C XML Schema, which is merely one of the several schema languages. SC34 has standardized RELAX NG, Schematron, and NVDL among others. / Allow schema languages other than W3C XML Schema, such as RELAX NG, Schematron, and NVDL, to be used for the validation of Custom XML and Structured Document Tags.
Ecma / Part 4, 3.17.7.185 / te / The formula DBCS is erroneously labelled as JIS. This is a localized string for representing the DBCS function in Japan. The actual function name and the storage in the file format is DBCS. / Change the function name from JIS to DBCS.
Ecma / All parts / ed / Change all occurrences of "may" to "can", "might", "should", or "shall", as appropriate. / Make this change.
Ecma / All parts / ed / Change all occurrences of "End example]", "End note]", "End rationale]", and "End guidance]" to "end example]", "end note]", "end rationale]", and "end guidance]", respectively, using the proper style. / Make this change.
Ecma / Schemas / ed / Since W3C XML Schema is merely one of the XML schema languages, always write "W3C XML Schema" when this particular schema language is meant. "Schema" and "XML schema" refer to any schema language such as RELAX NG.
Do not use the word "valid" when it does not mention validity against some schema. When it does mention validity, always make clear which schema is in question. (For example, what does "valid" in the third para of 2.5.2.6 of Part 4 mean?) / Make the requested changes.
Ecma / Part 4, 2.7 / te / Are section break properties allowed in style?
Since section breaks are paragraph properties the question is whether a section break can really be applied using a style? In other words, are the following style definitions valid?
<pre>
<w:style w:type="paragraph" w:customStyle="1" w:styleId="MyStyle">
<w:name w:val="MyStyle" />
<w:basedOn w:val="Normal" />
<w:pPr>
<w:sectPr>
<w:pgSz w:w="12240" w:h="15840" />
<w:pgMar w:top="1417" w:right="1417" w:bottom="1134" w:left="1417" w:header="708" w:footer="708" w:gutter="0" />
<w:cols w:space="708" />
<w:docGrid w:linePitch="360" />
</w:sectPr>
</w:pPr>
</w:style>
</pre> / Disallow section break properties in a style, either by making a schema change or by adding a constraint to the current schema.
Ecma / Part 4, 2.4 / te / Should two tables having the same properties, where one immediately follows the other, be merged? / Explain the intent is that these tables shall be merged
Ecma / Part 4, 2.3.2.28 / te / The rtl element should provide additional clarification w.r.t. its effects on bidirectional text. / Provide such clarification (e.g., something similar to the Unicode Bidi algorithm at
Ecma / Part 4, 3.17.7 / te / The specification for the trig functions does not specify whether input and output parameters that represent angles are in radians or some other unit. / State that all parameters (both input and output) that represent angles are in radians. This includes at least input arguments to SIN, COS, and TAN, as well as return values from ASIN, ACOS, ATAN and ATAN2. For every return value, specify the range of values (remembering that the inverse trigonometric functions are multi-valued).
Ecma / Part 4, 3.17.7.17 / te / AVEDEV shows an incorrect formula. / Use the correct formula.
Ecma / Part 4, 3.17.7.47 / te / CONFIDENCE function is light on specification. / Review this specification and augment, as necessary.
Ecma / Part 4, 3.17.7.48 / te / CONVERT doesn’t specify which “cup” or “tablespoon” version to use
Possibly provide a link to the NIST definitions: / Provide this information.
Ecma / Part 4, 3.17.7 / te / Some statistical functions say “x is the sample mean” rather than “x-bar is the sample mean” / They should say “x-bar” rather than “x”.
Ecma / Part 4, 3.17.7.33 / ed / CEILING - be clear in its definition as it is not the same as another CEILING (see / Make this clarification.
Ecma / Part 4, 3.17.7.48 / ed / In CONVERT, Pica (1/72") should be Point (1/72"). / Correct this.
Ecma / Part 4, 3.17.2.3 / te / The cell reference syntax seems to allow decimal numbers. It should not. / Restrict the numbers to integers.
Ecma / Part 4, 3.17.7 / ed / Most formulae are pictures of rather poor quality, and they don’t scale well. / Replace all formulae pictures with equivalent WordprocessingML equations.
Ecma / Part 2 / ed / "type" is sometimes used without qualification, which makes its meaning confusing. / Always qualify the use of the term "type"; e.g., "content type", "relationship type", and so on.
Ecma / Part 4, 2.18.51, 2.18.52, 5.1.12.72 / te / As discussed in a letter from the Linguistic Society of America to ANSI ( ST_Lang, ST_LangCode, and ST_TextLanguageID do not reference IETF BCP 47. / ST_Lang and ST_TextLanguageID should be changed to specify that the conventions defined in IETF BCP 47 ( are to be used. In addition, ST_LangCode should be removed.
Ecma / Part 1, Annex A / ed / Make annex normative and look at which, if any, entries can/should be moved to the "Normative References" clause. / Make this change.
Ecma / Part 2, Annex H / ed / This clause is titled “Conformance Requirements”, but it actually is informative material. Shouldn’t it be titled something more like “Best Practices”? / Change the title to "Requirements Reference".
Ecma / All parts / 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. Either correct the terminology to reflect that it is a multipart document, or turn it into a true multipart standard. / The project editor is open to NB suggestions on the final structure of the standard w.r.t to multipart document vs. multipart standard. In any event, it should be made one or the other, according to the JTC 1 Directives.
Ecma / Part 1, 7 / ed / This clause states, "Clauses 1–5, 7, and 9–14 form a normative part of this Part; and the Introduction, clauses 6 and 8, as well as the annexes, notes, examples, rationale, guidance, and the index, are informative." However, some annexes are normative, so this needs to be corrected. / Correct this clause.
Ecma / Part 4 / te / For accessibility purposes, each form control (i.e., SDT) should have the ability to specify a label. / Say that every form SDT should have an accompanying form "label", which is a separate SDT. The form SDT then has a "label" property which references the SDT (by id) that is the label for the form SDT.
Ecma / Part 4 / te / For accessibility purposes, there should be an explicit tab order for form controls (i.e., SDT). / Add a new element to the form control properties that is a "tab order" element. This applies to content controls.
Ecma / Part 4, 2.18.4 / te / For the collection of border styles, without providing them as separate resources (images) in an electronic annex, implementers need to copy paste them out of the spec directly. / Provide them as separate resources (vector images) in an electronic annex.
Ecma / Part 4, 2.7.6 / te / The specification must define each numbered style completely, and specify language dependencies. For example, in a US-English context, is the order A to Z, AA, BB, CC or A to Z, AA, AB, AC, or something else? Also, what do we do in Swedish or Greek, for example? / Fully describe each numbered style, including its language dependencies, and its behavior for arbitrarily large positive integers.
Ecma / Part 1, 3 / ed / A complete list of normative references according to international rules (referring to Approved Referencing Organization (ARO) or accompanied by a Referencing Explanatory Report (RER)) is expected. / Provide a complete list of normative references.
Ecma / All parts / te / There are editorial errors where WMF and EMF where directly and normatively referenced from within the specification. This should be fixed as no piece of OpenXML has a requirement on WMF or EMF. / This was an inadvertent editorial error. DIS 29500 enables the use of any graphic format. Remove these references.
Ecma / All parts / te / The spec appears to provide support for only one model of Object linking technologies. Consider supporting other models. / Expand the support for available Object linking technologies to include Object linking technologies from other platforms as well.
Ecma / All parts / ed / The specification sometimes incorrectly interchanges the terms “hex digit”, “hex octet”and “hex value”. / Review all occurrences of these terms to ensure that they are used correctly:
• A “hex digit” is a value in the range 0 to 15, represented as a character in the set 0-9, A-F.
• A “hex octet” is a value in the range 0 to 255 decimal, represented as a pair of hex digits.
The term “hex value” should not be used.
Ecma / Part 4, 5.7.3.46 / ed / Table 6, Default Data Point Formatting", runs off the right edge of the page. / Show the whole table.
Ecma / Part 4, 3.17.7.113 / te / The description for this function is incorrect. / Instead of "X is the value of the function", and "Lambda is the parameter value", the descriptions should be "X is the value at which the function will be evaluated" and "Lambda is the inverse of the mean".
Ecma / Part 4, 3.17.7.346 / ed / The "(di d1)" part of the formula seems to missing something; an operator, perhaps? / Change "(di d1)" to "(di - d1)".
Ecma / Part 4, 3 / te / The hashing algorithm for passwords in several subclauses of SpreadsheetML is incorrect and needs a minor update. / Correct and clarify the algorithm.
Ecma / Part 1 / te / The condition where the content type value is an empty string requires additional clarification. / The condition where the content type value is an empty string shall not be an error condition.
Ecma / Part 1 / te / The Digital Signature Relationships transform should explicitly call out how XML comments are to be handled / In Digital Signature Relationships transform, explicitly call out that removing element content includes removing comments.
Ecma / Part 1, 12.3 / te / Section 12.3 lists comments as a target of ChartSheet, but 12.3.2 says that only Printer Settings and Drawings are targets of chartsheet / Remove Chartsheet from the list of source parts for the Comments part in the table.
Ecma / Part 1, 13.3.6 / te / The table in 13.3 states that the Comment Authors part is a target of Presentation, but section 13.3.6 does not list CommentAuthors in the list of outgoing relationships from Presentation. / Add the Comment Authors part as a target of the Presentation part.
Ecma / Part 4, 2.16.4.1 / te / The date picture in the Fields section needs additional details for non-Gregorian dates. / Specify these details.
Ecma / Part 1, various / te / There are some content types that are inconsistent with the conventions set by the other content types. / Make the following corrections:
• 11.3.10 – Main document part should be application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml, which matches the approach taken for the templates content type.
• 13.3.7 – Presentation Properties content type should be application/vnd.openxmlformats-officedocument.presentationml.presProps+xml
• 12.3.23 – Workbook part should be: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.main+xml
• 15.2.9 – Embedded Object part should not have a fixed content type. Any type of content is allowed here.
• 15.2.10 – Embedded Package Part should not have a fixed content type. Any content type is allowed.
• 15.2.12 – The content types for fonts did not include one for obfuscated fonts (as described in Part 4 section 2.8.1). There should be an additional content type: application/vnd.openxmlformats-officedocument.obfuscatedFont.
Ecma / Part 1, 13.3.9 / te / “A package shall contain one or more Slide Layout parts, and those parts shall be the target of an explicitrelationship in the Presentation (§13.3.6) part, as well as an implicit relationship from the Slide Master(§13.3.10) part associated with this slide layout.”
This is incorrect. / Say instead that it’s implicit from Slide, explicit from Slide Master.
Ecma / Part 1, 12.3.13 / ed / The source relationship for the Pivot Table Cache Records part is mistyped. / Change it to
Ecma / Part 1, 13.3.12 / te / The text in quotes below is contradictory to the phrase preceding it:
A package shall contain zero or more User Defined Tags parts, "zero or one" as the target of an explicit relationship from the corresponding Presentation (§13.3.6) or Slide (§13.3.8) part. / Change it to “zero or more”.
Ecma / Part 1, 12.3.13 / te / The text in quotes below is incorrect:
A package shall contain "exactly one" Pivot Table Cache Records part per pivot table, and each such part shall be the target of an explicit relationship in the Pivot Table Cache Definition (§12.3.12) part for the corresponding pivot table. / Change it to “zero or one”.
Ecma / Part 1, 12.3.7 / te / The VML Drawing part should be listed as a child part of the Dialogsheet part. / Add this as an explicit child relationship (zero or one).
Ecma / Part 4, 2.3 / te / The description for toggle properties needs clarification. / State that toggle properties toggle between levels, not for style chains at the same level.
Ecma / Part 4, 7.1.2.84 / te / The default is listed as "top", but it should be "bot". / Make it "bot".
Ecma / Part 4, 5.1.5.2.4 / te / Provide additional information on the grammar and semantics for fld element’s type attribute. / Provide this information.
Ecma / Part 4, 5.1.5.3.7 / te / Provide additional information on the grammar and semantics for latin element’s charset, pitchFamily, typeface attributes. / Provide this information.
Ecma / Part 4, 4.6.28 / te / Provide additional information on the grammar and semantics for cmd element’s cmd attribute / Provide this information.
Ecma / Part 4, 4.6.79 / te / Provide additional information on the grammar and semantics for tav element’s fmla attribute / Provide this information.
Ecma / Part 4, 4.6.3 / te / Provide additional information on the grammar and semantics for animEffect element’s filter and prLst attributes / Provide this information.
Ecma / Part 4, 4.6.75 / te / Provide additional information on the grammar and semantics for strVal element in PresentationML / Provide this information.
Ecma / Part 2, 12.2.4.26 / te / Dig Sig should carefully specify how canonicalization processes relationships that are missing optional attributes. / For relationships that are missing optional attributes,.add the following text after Step 3 inthe Relationship Transform Algorithm section:
4. The package implementer shall add TargetMode attribute with default value, if the optional attribute is missing for the Relationship element.
Ecma / Part 4, 3.3.1.14 / te / The theme attribute is claimed to be an index into the <clrScheme> collection, which sounds like an index into its child element position (which is also analogous to other indices used in Office Open XML). The theme attribute values are mapped to names of theme colors (bg1, tx1, bg2, etc.); however, this mapping is not documented. / Provide the mapping for the theme attribute.
Bg1 = 0
Tx1 = 1
Bg2 = 2
Tx2 = 3
Accent1 = 4
Accent2 = 5
etc.
Ecma / Part 2 / te / Dig Sig should carefully spec how the canonicalization process handles empty elements: e.g., "<a</a>" versus "<a/>". / Specify that all empty elements shall be treated as start/end element pairs during the canonicalization process.
Ecma / Part 4, 3.17.7.249 / ed / The example displays 10 digits. The value of PI should be shown as accurate to 15 digits. / Fix the example.
Ecma / All parts / ed / There are a number of broken references (of the form '§0'). / Fix such broken references.
Ecma / Part 4, 2.3.1 / te / There is some ambiguity as to which paragraph properties are, and are not affected, by the bidi element within the pPr element. / Specify explicitly which properties are, and are not, affected by this setting.
Ecma / Part 2 / te / The case in which a Relationships Part does not contain any Relationships, requires additional clarification. / The minimum requirement for a Relationships Part, when present, is its root element <Relationships/>.
1MB = 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 **)