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

Office Open XML Overview
GB Throughout   ed 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. Proposed change: Change the name of Office Open XML to a name which is not confused with OpenOffice. SC34 standards usually end with 'DL' (description langage) 'SL' (schema language), etc. For DIS 29500 a suitable name is ODDL (Office Document Description Language), which would remedy the fault noted.

The standard must refer to its proper name throughout (or “this international standard”) rather than sometimes adopting ad hoc alternative forms (e.g. “Open XML” in the present DIS).

 
GB Throughout   te The UK considers it critical that the text makes clear statements on conformance.

The text must make clear throughout that purely syntactic conformance is not enough for a implementation to claim it is conformant. The text must describe conformance in terms of semantics which have to be observed (though not necessarily replicated) by conformant applications.

Proposed change: What is required, and what is optional, for conformance must be clearly distinguished within the text.  
GB Throughout   te It must be possible to process data within office documents using standard tools for processing XML files, including tools that can process XML Schema Datatypes. In many cases the same sort of data is recorded in different ways in the various sections of the DIS. Obvious examples are the way in which dates are recorded in word processing documents and spreadsheets, and the way binary data is identified.

It must be possible to identify and record an XSL processable form of every datatype represented in an OOXML document. For example, every element recording a date should be qualified with an attribute whose value is a processable xsd:date (or xsd:dateTime) representation of the recorded date. All integer, real and currency datatypes that are referenced in spreadsheet formulas should also be appropriately datatyped. Similarly every element containing binary data, or extensions that need to be processed using a non-XML processor, should have an attribute that records the MIME type of the data to be processed.

This suggestion does not imply that all data that is processed as strings should need to be datatyped (as it is in languages such as the Web Ontology Language – OWL).

Proposed change All atomic values in the XML which have the same type should use the same typing scheme (e.g. dates should all conform to ISO 8601). Where possible this scheme should be an ISO or W3C XML scheme, and identified as such.

All mechanisms that allow referral to external and/or non XML resources should provide a means of identifying those resources’ media types using the MIME scheme.

 
GB 4.1 Interoperability [p3]   ed “Foremost, the interoperability of OpenXML has been accomplished through extensive contributions, modification, and review of the Specification by members of the Ecma TC45 committee...”

OOXML has not yet been proven to be interoperable, as no conforming consumers and producers have yet been created. This claim cannot be made until more than one full implementation of an application that produces and consumes conformant OOXML exists. This is made difficult by the problems with the conformance definition in Part 1 - Fundamentals as described elsewhere in these comments.

Remove inappropriate PR hyperbole from the text.  
GB 4.1 INTEROPERABILITY [p4]   ed References in the following bulleted list refer to the wrong sections:
  • OpenXML contains no restriction on image, audio or video types. For example, images can be in GIF, PNG, TIFF, PICT, JPEG or any other image type (§1:14.2.12).
  • Embedded controls can be of any type, such as Java or ActiveX (§1:15.2.8).
  • WordprocessingML font specifications can include font metrics and PANOSE information to assist in finding a substitution font if the original is not available (§3:2.10.5).
Proposed change: Change the references to
  • OpenXML ... (§1:15.2.13). - for "15.2.13 Image Part"
  • WordprocessingML font ... (§3:2.9.5). - for "2.9.5 Font Substitution Data"
 
 
GB 4.1 INTEROPERABILITY [p4]   te “One of the central requirements for interoperability is independence from any particular type of source content.”

This claim is dubious, and relies on the absence of a clear definition of “interoperability” in the specification. The UK assumes that one of the meanings of interoperability involves the ability for Application A to produce an OOXML file, that can be consumed by Application B, presented to the user with 100% fidelity, edited and saved, then consumed by Application N, still with 100% fidelity of representation.

If this is the case, it seems logical that a central requirement would be for clear standards-based specification of source content, such that a future consuming application, unknown to the producer, has clear expectations of the valid range of content found within a conforming OOXML file. Interoperability between applications requires rules that impose constraints, whereas “independence from any particular type of source content” implies a lack of determining structure. If a conformant OOXML file can contain any type of source content, conforming consumers will have to support any type of source content - which is clearly impossible

Proposed change: The standard must supply a precise definition of “interoperability”, and relate it to a definition of conformance as per the comment on conformance above.  
GB 5.2 WORDPROCESSINGML [p11]   te r – run (§3:2.4.2). The description of a run is confused about whether it is limited to text-only, and whether it contains additional markup. "[A run] Can contain multiple types of run content, primarily text ranges. ... A run is a contiguous piece of text with identical properties; a run contains no additional text markup." Part 3 and Part 4 reiterate "...the run, which defines a region of text..." [Implied "text-only" is wrong] Part 3 and Part 4 define with many examples that the run can contain a range of additional text markup in child elements like delText, endnoteRef, fldChar, ... (e.g., see §4:2.3.2.23). Part 3 and Part 4 also define that the run can contain non-text items like drawing (DrawingML Object), object (Inline Embedded Object), pict (VML Object), ... (e.g., see §4:2.3.2.23). Proposed change: Clearly define the general concept of a run that can contain multiple types of content, primarily a text range with the same properties. [If the primary intent of a run is for text rather than other content types - if not the primary intent, use words like "such as a text range ...".] This also needs changes to the sections in Parts 3 and 4, including section titles that imply runs are only for text. [The text content is defined by a sub-element, t. §4:2.3.3.30]  
GB 5.2 WORDPROCESSINGML [p11]   te t – text range (§3:2.4.3.1). The statement about text formatting inheritance from run properties and paragraph properties is too limiting, because it does not account for the entire style hierarchy, as alluded to in the following paragraph in the Overview. Proposed change: Change sentence to indicate inheritence from style hierarchy. "The formatting for the text is inherited from any run properties and paragraph properties, and from the higher style hierarchy as outlined in the following paragraph."  
GB 5.2 WORDPROCESSINGML [p11]   te t – text range (§3:2.4.3.1). Is it OK to define OOXML attributes and behaviour within another standard (the separate XML 1.0 specification)?

I believe that preserve whitespace is not "often" used, for routine text runs (only likely if several text runs need to be merged? If preserve is "often" used, why is the WordprocessingML default to remove white space?

Proposed change: Change sentence to clarify use of the xml:space="preserve" attribute.  
GB 6 SUMMARY [p13]   ed "OpenXML ... and its documentation has become both complete (through extensive reference material) ..."

The documentation is not complete (yet?) which in part is a reason for the review process.

Proposed change: Change sentence to state OpenXML ... and its documentation includes extensive reference material ...  
GB 6 SUMMARY [p13]   ge "The compelling need exists for an open document-format standard that is capable of preserving the billions of documents that have been created in the preexisting binary formats,..." As stated, the need is for an open document-format standard that is capable of preserving the documents. This does not mean that the standard has to be a new XML representation of the preexisting binary formats. There is already an open document-format standard that is capable of preserving the documents, and that already has widespread use and for some time its evolution has "enjoyed the checks and balances afforded by an open standards process".

If the Summary needs a statement about the need for an OOXML standard, it should qualify if there is a need for another open document-format standard alongside existing established standards, and how the new standard will interoperate with established standards.

Remove inappropriate PR hyperbole from the text  
Part 1  - Fundamentals
GB General   te
Namespace prefix mappings

There is no table listing an explicit mapping between the namespace prefixes used in the rest of the specification and their namespace URIs. This makes developing an application that uses these examples significantly more difficult.

Remedy - add a table, listing all the namespace prefixes and their associated URIs.  

(Not part of the specification, but a recommendation: ensure that these URIs also resolve as URLs to web pages containing documentation about the namespace and a link to the schema for it)

 
GB General   ed
Definition of "deprecated" and "legacy"

Various parts of the specification are described as "legacy" and "deprecated", such as the entire VML section, and specific parts of other sections such as the autoSpaceLikeWord95 element. However, these descriptions are informative, rather than normative. In addition, there is no mandated behaviour associated with these deprecated sections. The commonly accepted meaning of "deprecated", when applied to an application using OOXML, would be that an application should be able to read deprecated elements (subject to the limitations described in 2.6), but would not write them out, except when they already existed in the source document. No non-deprecated sections of the specification should depend on deprecated sections.

Proposed change: Deprecated and legacy parts of the specification should be marked as deprecated in normative text. A definition of deprecation and the associated behaviour should be included in this document. The specification should make it clear that applications conforming to the OOXML specification should not produce new instances of deprecated elements or attributes. Existing non-deprecated parts of the specification dependent on deprecated sections should either be changed to use non-deprecated sections, or be deprecated themselves (so the "background" element in WordProcessingML should be changed to use DrawingML, for example).  
GB General   ed The word "will" is used inappropriately throughout all Parts of the standard. It generally should be used only for an event at some indeterminate future time. Proposed change: Replace the use of "will" with the correct present definite tense. For example, "The numbering definition part will contain the definition for..." should become "The numbering definition part contains the definition for..." and "This simple type specifies that its contents will contain ..." should become "This simple type specifies that its contents contain ..."  
GB Foreword [xi]   ed The "Office Open XML Overview" 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. Proposed change: 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.  
GB

    Introduction [xii]

  te Claims that this text will enable implementation "in a way that is fully compatible with the large existing investments in Microsoft Office documents". Yet there is no mapping provided between DIS 29500 and existing (legacy) Office document formats. Proposed change: Provide such a mapping or remove this claim.  
GB Section 2 – Conformance   te The conformance section fails to provide a testable definition, defining conforming documents tautologically as “documents which conform”. It raises a series of issues, and includes an “informative” guidelines section that indicate loopholes in conformance, without then closing them off.

The three goals of the standard introduce a broad set of objectives that contain contradictions. Innovation, interoperability and preserving investment in existing files have different requirements.

  • The first implies that consumers not be constrained to reproduce exactly what the originating producer created, and that different producers could differ in some manner with the same raw content.
  • The second implies that the opposite is true, that consumers can reproduce exactly what producers originated.
  • The third implies that non-conformant documents produced by applications that know nothing of OOXML e.g. very old versions of MS Office, can be converted into conforming OOXML and consumed in such a way as that they are exactly as originally intended with no further effort or investment.
Proposed change: (as above) what is required, and what is optional, for conformance must be clearly distinguished within the text. Clarify the meaning of this text  
GB 2 [p2]   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? Proposed change: Either remove this sentence or clarify how or where something “documented otherwise” can change how something specified in the normative text.  
GB 2.1 [p2]   ed There are no normative statements in this clause, though Section 2 is indicated to be normative Proposed change: Mark clause as informative using one of the mechanisms of Section 7  
GB 2.2 [p2]   ed There are no normative statements in this clause, though Section 2 is indicated to be normative Proposed change: Mark clause as informative using one of the mechanisms of Section 7  
GB 2.2 Issues   te Whether normative or informative, there are a variety of problems with the text:
  • Issue 1, line 21-25 “stipulating visual layout would be inappropriate for a consumer that extracts data for machine consumption, or that renders text in sound.” The statement implies visual layout should not be stipulated at all, where in fact the correct approach would be to include both specifications for visual layout, and additional meta-data for circumstances where the document is rendered in audio. A consumer that “extracts data for machine consumption” would simply ignore all HCI information completely.
  • Issue 2, line 26-30 “Commonsense user expectations regarding the interpretation of an Office Open XML package (§4) play such an important role in that package's value that a purely syntactic definition of conformance would fail to effect a useful level of interoperability.” This statement has two problems. 1) It states that purely syntactic conformance will fail to deliver interoperability, but sub-clauses 2.4 and 2.5 define document and application conformance as “purely syntactic” so by inference, this standard must fail to achieve interoperability. 2) More importantly, the concept of “common sense” is far too ambiguous, indeterminate, and culturally blind to play a role in an international standard. Your commonsense is not my commonsense, or the commonsense of a user in India or China. Such a non-precise concept cannot aid interoperability or achieving conformance.
  • Issue 3 “Legitimate operations on a package include deliberate transformations, making blanket change prohibitions inappropriate in the conformance definition.” What are blanket change prohibitions? Surely the conformance definition only specifies the initial state of a conforming file. Once an application starts to transform it, deliberately or not, it is entirely possible that the file will end up non-conformant, e.g. it could be transformed to ODF, or PDF, or a binary MS format. What is the point of this issue? “Again, commonsense user expectation makes the difference.” Difference to what?
Revise the text to address these concerns.  
GB 2.3 What this Standard specifies [p3, 9]   te “this Standard constrains both syntax and semantics,” but then both document and application conformance are stated to be “purely syntactic”. Only sub-clause 2.6 Interoperability Guidelines refers to the use of semantic specifications, and this section is marked as Guidance so is informative, not normative. In what sense does the standard constrain semantics, if they are purely normative, and conformance does not require semantics to be accounted for? Proposed change: (as above) what is required, and what is optional, for conformance must be clearly distinguished within the text. Clarify the meaning of this text  
GB 2.3 [p3, 14]   te 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? Proposed change: 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  
GB 2.3 [p3, 16]   te 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? Proposed change: Clarify the use of the word “element” perhaps by saying “XML element” if that is what is meant.  
GB 2.4 [p3, 22]   ed This line require conformance with “Unicode Standard” without specifying a version. XML 1.0 referred to Unicode 2.0, though the informative Appendix A of OOXML Part 1 lists Unicode 4.0. Which is it? Proposed change: An explicit Unicode version reference should be made in the Conformance section.  
GB 2.6 [p3, 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. Proposed change: Change to read, “a software application should be accompanied by documentation...”  
GB 2.6 [p3-34 to p4-6]   te The ability to allow different applications of OOXML to implement individually selected sets of optional features, and to "highlight any behaviors that would, without that documentation, appear to violate the semantics of document" means that it will be impossible for OOXML implementations to interoperate. As this statement is not normative it is not necessary for implementations to document apparent violations of semantics, which will make interoperability harder to achieve.

[To expand on this point slightly in less formal language - the problem is that two independent implementations of the specification can choose a different subset to implement, and still be described as conforming to the OOXML specification. For example, two different wordprocessors can each choose to implement 90% of the specification, but each will implement a different 90%. The size and complexity of the specification means that this is highly likely to happen in practice (and an inspection of the existing ECMA 376 implementations shows that this is already starting to occur). Then, interchanging documents between those two wordprocessors will not work reliably - and ISO's goal of "compatible technology" will not have been achieved. The argument could be made that there are certain base functions that must be implemented by any wordprocessor (such as headings, paragraphs, text formatting, etc.), and so these most important functions will be fully interoperable - but this definition of basic functions should be embedded in the standard]

Proposed change: There should be a normative definition of what an application needs to support in order to conform to this specification. This definition should define a clear list of elements and attributes that are required to be supported by an implementation in order for it to be described as conforming to the specification. This definition should not include any deprecated elements or attributes. This definition should be created with practical interoperability between OOXML implementations in mind.  
GB 2.6 [p4, 2-6]   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? Proposed change: Clarify the use of the word “element” perhaps by saying “XML element” if that is what is meant.  
GB 2.6 [p4, 15]   ed Obviously the Standard anticipates such behavior since it explicitly contains the present example describing this behavior and calls it conforming. Proposed change: Perhaps it is meant to say, “...this Standard does not recommend this behavior”.  
GB 4 [p6, 9]   ed (behavior, implementation-defined) “application-specific”, at least in common standards use, is not the same as application-defined, viz. ANSI C Programming Language Proposed change: Use “application-defined” consistently where the intent is for applications to document their behavior.  
GB 4 [p6, 13]   te (behavior, unspecified) This definition doesn't work, because 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. Proposed change: Clarify this definition. Perhaps it is meant to say, “Behavior for which this Standard does not make a recommendation”?  
GB 4 [p7, 1]   te (Office Open XML Document) 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? Proposed change: Clarify the definition  
GB 5 [p8, 3-13]   te Notation conventions 3, 4 and 6 appear to rely upon styles that are not visually distinguishable in the version of the specification under review. Proposed change: If the stylistic distinction is necessary, the styles should be made clearly distinct for both screen-based and paper-based readers.  
GB 8.6.5 [29-30]   te Should be revised to read as follows (the problem is that "Math" is not a tag): Math is used, mainly in documents, to specify the structure and appearance of equations. The outermost element is oMath or oMathPara, a paragraph with one or more equations where each equation is specified using a single oMath element.  
GB 9.1.1 [p16, 10]   te ASCII requires a normative reference since there are several national variations. Proposed change: Suggest reference be made to ISO/IEC 646:1983 or ANSI X3.4-1986  
GB 9.1.5 [p16, 25]   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. Proposed change: If interleaving is not permitted then it should not be described in Part 2.  
GB

    9.1.7 [p17, 7]

  te The naming convention given is incorrect. H is a hexadecimal digit, not a hexadecimal value. Proposed change: Follow correct usage pattern as established earlier in 9.1.1.  
GB 9.1.9 [p17, 25]   ed Incorrect subject. A producer qua producer does not round trip Proposed change: Should say, “Conforming producers that are also consumers should...”  
GB 9.2 [p18, 8]   ed Extra full stop following “explicit.” Proposed change: Remove extraneous punctuation  
GB 10.1.2 [20]   ed Reference is made to material in Part 12, Clause 12. Although a clause of that number does exist, it does not contain the material 10.1.2 references it for. Proposed change: Correct the reference to point to the correct clause.  
GB 11.3.1 [15-17]   ed 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. Proposed change: 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...”  
GB 12.3.5 [p68]   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. Proposed change: Fully define the use of Custom Property Part  
GB 14.2.2 [p126 18]   te We believe from the schemas that the root namespace here may be http://schemas.openxmlformats.org/drawingml/2006/chartDrawing, rather than http://schemas.openxmlformats.org/drawingml/2006/chart. Remedy: confirm that this is correct, and update the namespace accordingly.  
GB 15.2.6 [p142 3]   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? Proposed change: Clarify the meaning.  
GB

    15.2.8

    [p143 -146]

  te The examples given are rendered useless by the predominance of the VML in the markup. Proposed change: Make a more succinct and clear example by concentrating on the control persistence.  
GB 15.2.12 [p154]   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” Proposed change: Provide reference to intended specifications for TrueType and OpenType  
GB 15.2.14 [p155]   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. Proposed change: 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.

Adopt such an alternative.

 
GB 15.2.15 [p156]   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. Proposed change: Clarify what size the thumbnails should be, or that the images are scaled.  
GB Annex A [p162 7]   te The reference given for the Zip format does not provide a date or version, though this specification is frequently revised, Proposed change: Reference should be made to a particular dated and labeled Zip version.  
Part 2 – Open Packaging Conventions
GB General   te 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. Proposed change: 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.  
GB 1 Scope [p1, 9]   te The 'well-defined naming guidelines' expression is an oxymoron in the context of a standard. This is reinforced in the case of OOXML proposal by the fact that 'guidance' parts of the text are explicitly meant to be informative only (as opposed to normative). Proposed change: Replace 'guidelines' with 'rules'.  
GB Page 2 Normative References   ed The normative references listed here include only ISO and ISO/IEC standards, while the normative body of the text makes reference to many other specifications, such as RFC3986, RFC2616, XML Schema Part 2: Datatypes, ZIP specification, XML-Signature Syntax & Processing (most of the bibliography entries could be moved to normative references). All normative standards should be referenced as such (whether ISO/IEC standards or not)  
GB 3 Definitions [p4, 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. Proposed change: Define 'package model' in unambiguous terms and use the resulting definition consistently throughout the OOXML text.  
GB Page 9 line 25   ed This line references "a note as specified in 4.1, “Document Conventions.”", but there's nothing in 4.1 describing notes. Either 4.1 needs a description of a note to be added, or this cross reference must be removed. Without knowing how "standard" the use of notes is in this standard according to Ecma procedures, it is not possible to suggest which is better.  
GB Page 10 lines 13-15   ed The second sentence in this paragraph is normative text in a clause explicitly described as informative. It would be better to make this whole paragraph normative, but that may cause problems as the normative/informative split in this Ecma standard appears to be at the level of whole clauses, except where notes are used. A change in the normative/informative status of the clause would also require changes in section 6. No proposal  
GB Page 12 line 3   ed It looks as if this line should have been a sub-clause (8.1.1.1) No proposal  
GB Page 62 line 4   ed Missing space in "SignatureValueelement". should be "SignatureValue element"  
GB Page 80 line 2   ed Incorrect cross-reference this one should be [M3.21]  
GB ANNEX A [p81, OpenPackagingConventions-XMLSchema.zip ]   ed There is no explicit indication given as to whether this annex is informative or normative. See ISO Directives, Part 2, section 5.2.6. Proposed change: Clarify the status of this annex.  
GB ANNEX A [p81, OpenPackagingConventions-XMLSchema.zip ]   ed This annex was not provided in a humanly-readable citable format as required by JTC1 Directives 8.3.5 and Annex H. Proposed change: 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.  
GB Page 82 line 5   te It is stated "If discrepancies exist between the electronic version of a schema and its corresponding representation as published in this part, Part 2, the electronic version is the definitive version.". The editor must ensure no such discrepancies exist, as the published schema examples are normative  
GB ANNEX B [p82, OpenPackagingConventions-RELAXNG.zip ]   ed There is no explicit indication given as to whether this annex is informative or normative. See ISO Directives, Part 2, section 5.2.6. Proposed change: Clarify the status of this annex.  
GB ANNEX B [p82, OpenPackagingConventions-RELAXNG.zip ]   ed This annex was not provided in a humanly-readable format as required by JTC1 Directives 8.3.5 and Annex H. Proposed change: 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.  
Part 3 - Primer
GB 2.4.1 [36]   ed (The same phrase is also used on p34 in 2.3.1 [28] of the WordprocessingML Reference Manual.) Replace "... a designating specifying ..." with "... an attribute specifying ..."  
GB 2.4.2 [9 on p5]   ed Run properties are not represented by the r element. Proposed change: Change the order or the sentence to more directly relate the r element to the run. "The next level of the document hierarchy is the run, which defines a region of text with a common set of 9 properties. A run is represented by an r element, which allows the producer..."  
GB 2.4.2 [30 on p5]   ed wrong style: "emphasized" should be in italics.  
GB 2.4.2 [4 on p6]   ed Missing forward slash from end tag: </w:rPr>  
GB

    2.4.2 [17 on p6]

  ed Missing forward slash from end tag: </w:rPr>  
GB 2.4.2 [23 on p6]   ed Missing forward slash from end tag </w:rPr>  
GB 2.4.2 [28 on p6]   ed - Insert "of" in "... only some of the text ..."  
GB 2.5.2 [17]   ed Missing closing double quotes in attribute: w:sz="4"  
GB 2.5.3 [5 on p12]   ed Replace curly quotes with straight quotes: w:val="2"/>  
GB

    2.5.3 [26 on p12]

  ed Replace curly quotes with straight quotes: w:val="2"/>  
GB 2.5.4 [31 on p13]   ed 'W' in 'World' should be lower case: <w:t>Hello, world</w:t>  
GB 2.5.4 [13 on p14]   ed - Delete line 13: "..."  
GB 2.5.4 [16 on p14]   ed - Replace "5145" with "7368" to make consistent with example on p12: w:w="7368"  
GB 2.5.4 [23 on p14]   ed - Replace "2145" with "1488" to make consistent with example on p12: w:w="1488"  
GB 2.7.1 [1 - 28 on p28]   ed - Delete lines 1 to 28 as the same listing is on the previous page.  
GB 2.8.2 [2 on p30]   ed - "h" in "heading 1" should be upper case: <w:name w:val="Heading 1"/>  
GB 2.8.2 [6]   ed It appears that the child w:priority of w:style has been changed to w:uiPriority in the schema and in the tables in the Language Reference but has not been changed in any of the examples throughout the documents I've seen so far. Replace "w:priority" with "w:uiPriority"  
GB 2.8.2 [21 - 31 on p30]   ed - Delete lines 21 to 31  
GB 2.8.2 [32 - 33 on p30]   ed - Move lines 32 to 33 to between lines 12 and 13 on p30.  
GB

    [2.8.4 [27]

  ed See 2.8.2 [6] above. Replace "w:priority" with "w:uiPriority"  
GB 2.8.5 [31]   ed - Change line 31 to include the information from lines 28 to 29 on p34 (see below) to: "Consider the following two styles comprising a linked style pairing which defines: font = Arial, font color = green, paragraph spacing = double, indent = 1" left. The resulting style definitions would be:"  
GB 2.8.5 [28 on p34 - 14 on p35]   ed The xml listing for the linked styles is repeated unnecessarily. Move lines 28 and 29 on p34 and merge with line 31 on p33, as specified above. Delete from line 30 on p34 to line 14 on p35.  
GB 2.8.6 [17]   ed See 2.8.2 [6] above. Replace "w:priority" with "w:uiPriority"  
GB 2.8.7 [15 on p38]   ed See 2.8.2 [6] above. Replace "w:priority" with "w:uiPriority"  
GB 2.8.11 [26]   ed Incorrect attribute name Replace "w:defPriority" with "w:defUIPriority"  
GB 2.8.11 [31]   ed See 2.8.2 [6] above. Replace "w:priority" with "w:uiPriority"  
GB 2.8.11 [32]   ed See 2.8.2 [6] above. Replace "w:priority" with "w:uiPriority"  
GB 2.8.11 [35]   ed See 2.8.2 [6] above. Replace "w:priority" with "w:uiPriority"  
GB 2.8.11 [36]   ed See 2.8.2 [6] above. Replace "w:priority" with "w:uiPriority"  
GB 2.8.11 [1 on p43]   ed See 2.8.2 [6] above. Replace "w:priority" with "w:uiPriority"  
GB 2.8.11 [2 on p43]   ed See 2.8.2 [6] above. Replace "w:priority" with "w:uiPriority"  
GB 2.8.11 [3 on p43]   ed See 2.8.2 [6] above. Replace "w:priority" with "w:uiPriority"  
GB 2.8.11 [4 on p43]   ed See 2.8.2 [6] above. Replace "w:priority" with "w:uiPriority"  
GB 2.8.11 [5 on p43]   ed See 2.8.2 [6] above. Replace "w:priority" with "w:uiPriority"  
GB 2.8.11 [6 on p43]   ed - Add slash to close element.  
GB 5.9.4.3 [33 on p344]   ed - Replace curly quotes with straight quotes in XML attributes.  
GB

5.9.4.3.1 [29 on p345]

  ed - Replace curly quotes with straight quotes in XML attributes.  
GB 5.12.3 [p356-7]   ed The XML example is not well-formed. Although it is acceptable to use ellipsis to elide some information in examples, that should not include the key parts of the example (i.e. the rectangle shape, in this instance). Proposed change: correct the example to be well-formed and to provide useful information.  
GB 5.14.3 [p373-4]   ed The XML example is not well-formed. Although it is acceptable to use ellipsis to elide some information in examples, that should not include the key parts of the example (i.e. the rectangle shape, in this instance). Proposed change: correct the example to be well-formed and to provide useful information.  
GB 5.15.3.1.3 [20 on p379]   ed - Add missing quote at end of maxOccurs attribute  
GB 5.15.3.1.4 [5 on p380]   ed - Add missing quote at end of CT_Cxn attribute value.  
GB 5.15.4.1 [26 on p382]   ed - Add missing quote at end of lang attribute value.  
GB 5.15.4.1.3 [15 on p384]   ed - Add missing quote at end of CT_Colors attribute value.  
GB 5.15.4.1.6 [9 on p386]   ed - Add missing quote at end of styleLbl attribute value.  
GB 5.15.4.1.6 [10 on p386]   ed - Remove extraneous text "odoc".  
GB 5.15.5.1.3 [33 on p389]   ed - Remove backtick at end of line.  
GB 5.15.6.3.1 [25,26 on p403]   ed - Add missing quotes around "NAME OF TYPE" and "NAME OF SIMPLE TYPE"  
GB 5.15.6.3.16 [11 on p407]   ed - Add missing quote and space to break up animLvl from type attribute.  
GB 5.15.6.3.39 [16 on p415]   ed - Add missing quote at end of minOccurs attribute.  
GB 7.1   ed On page 1, the Primer states that "this Part contains a detailed introduction to the following Office Open XML topics" and includes "Various shared MLs" in the list. However as far as the "detailed introduction" is concerned:
  1. There is no example xml in 7.1. Perhaps this is why it contains only 7 pages.
  2. Looking at the provided docx files, there are only four expressions where oMath has been used. All the rest are picture elements. This explains why the layout looks poor e.g., the baselines are wrong. All the example mathematical expressions must be written using oMath.
  3. In maths, an expression is not always an equation. If anything, an equation is a maths expression that includes an equal sign, for example. It would be better to use "expression" or "mathematical expression" throughout.
  4. There is no association between maths and the xml being used in oMath. For example, a maths expression is composed of subexpressions but there is no description of how to go from the mathematical structure to the xml (cf presentation markup in MathML). Other parts of the Primer go into great detail about how the structure of a table or list, say, maps to the xml elements and it should be the same for maths.
  5. Some examples of how oMath fits with WordprocessingML would have helped to illustrate how paragraphs can be constructed. This type of example is used in other parts of the Primer.
  6. There is no description of what an operator is and how it is displayed differently to other objects. References are made to such things as "the alignment and manual break properties of operators" but these are not explained.
Revise the text to address these concerns  
GB 7.1 [18]   ed The expression "abc" with the arrow and with the brace over the top are both repeated. In each case, one is oMath and the other is a picture. The picture version needs to be deleted in each case.  
GB 7.1 [19]   ed The bar fraction "n/k" at the end of the line is repeated. One is oMath and the other is a picture. The picture version needs to be deleted.  
GB 7.1 [20]   ed The stack object, n over k, at the start of the line is repeated. One is oMath and the other is a picture. The picture version needs to be deleted.  
GB 7.1.10 [5]   ed - Replace "x + x + x" with "x + x + ...".  
GB

    7.1.12 [11]

  ed - Replace "upper limit" with "lower limit".  
GB 7.2.1 [6 on p440]   ed Missing forward slash from end tag: </dc:creator>  
GB 7.4.3 [7 - 8 on p445]   ed - Insert new line between lines 7 and 8 containing missing end tag: </b:NameList>  
GB 7.4.3 [14 - 15 on p445]   ed - Insert new line between lines 14 and 15 containing missing end tag: </b:NameList>  
GB 7.4.3 [21 - 22 on p445]   ed - Insert new line between lines 21 and 22 containing missing end tag: </b:NameList>  
GB 8.3.4.2.1 [2 - 9 on p470]   ed XML example not well formed. Insert missing end tags for choice and fallback.  
GB 8.3.4.1.1 [p455]   ed The graphic provided in the example is almost impossible to read, and includes malformed XML. Proposed change: Make an easy to read example (perhaps lighter background color) and make the example well-formed.  
 


 

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 98

ISO electronic balloting commenting template/version 2001-10


Top