Part 1 - Fundamentals
From OOXML-Wiki
[edit] Not present in document
[edit] 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)
[edit] 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).
[edit] Throughout
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 ..."
[edit] Foreword [xi]
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.
[edit] Introduction [xii]
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.
[edit] Section 2 – Conformance
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.
[edit] 2 [p2]
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.
[edit] 2.1 [p2]
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
[edit] 2.2 [p2]
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
[edit] 2.2 Issues
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?
[edit] 2.3 What this Standard specifies [p3, 9]
“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?
[edit] 2.3 [p3, 14]
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.
[edit] 2.3 [p3, 16]
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.
[edit] 2.4 [p3, 22]
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.
[edit] 2.6 [p3, 33-34]
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...”
[edit] 2.6 [p3-34 to p4-6]
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.
[edit] 2.6 [p4, 2-6]
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.
[edit] 2.6 [p4, 15]
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”.
[edit] 4 [p6, 9]
(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.
[edit] 4 [p6, 13]
(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”?
[edit] 4 [p7, 1]
(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
[edit] 5 [p8, 3-13]
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.
[edit] 8.6.5 [29-30]
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.
[edit] 9.1.1 [p16, 10]
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
[edit] 9.1.5 [p16, 25]
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.
[edit] 9.1.7 [p17, 7]
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.
[edit] 9.1.9 [p17, 25]
Incorrect subject. A producer qua producer does not round trip.
Proposed change: Should say, “Conforming producers that are also consumers should...”
[edit] 9.2 [p18, 8]
Extra period following “explicit.”
Proposed change: Remove extraneous punctuation
[edit] 10.1.2 [20]
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.
[edit] 11.3.1 [15-17]
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...”
[edit] 12.3.5 [p68]
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
[edit] 14.2.2 [p126 18]
I 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.
[edit] 15.2.6 [p142 3]
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.
[edit] 15.2.8 [p143-146]
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.
[edit] 15.2.12 [p154]
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
[edit] 15.2.14 [p155]
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.
[edit] 15.2.15 [p156]
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.
[edit] Annex A [p162 7]
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.
