Template for comments and secretariat observations Date: 2007-08-28 Document: ISO/IEC DIS 29500
 
1 2 (3) 4 5 (6) (7)
MB1 
Clause No./ 
Subclause No./ 
Annex 
(and.g. 3.1)
Paragraph/ 
Figure/Table/Note 
(and.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

PT       ed The document does not conform to the ISO/IEC Directives Part1, 2.14 RAND access must be mentioned in the introduction.  
PT 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, whether informative or normative. If it is merely a promotional whitepaper about Ecma 376, then it should not be included in the published standard.  
PT No clause. This is the question.   ge Based currently on the implementation of ECMA specification 376, Microsoft makes it possible for implementers to choose between either a CNS (Covenant Not to Sue) or an OSP (Open Specification Promise) as (currently) mentioned at http://www.microsoft.com/interop/osp/default.mspx

Considering that external references tend to be of a volatile nature, it is crucial to include at the beginning of the specification whatever advantages/legal protection mechanisms that the implementer has to ensure his ongoing compliance.

To further ensure the implementer's security, the specification should state the non-applicability of copyrights, patents or royalties.

Include at beginning of specification a list of all Microsoft and non-Microsoft CNS's or OSP's that might help clarifying the legal background for implementing the specification and that will help ensuring full protection for the implementer, mentioning any issues regarding patents, royalties and copyrights whenever necessary.

Consider replacing the promise-not-to-sue approach by a patent grant, which translates better to the existing legislation.

 
PT No clause. This is the question   ge As pointed out in the previous item, and as per the MOSP (Microsoft Open Specification Promise), only the Specifications included in that promise (Covered Specifications) are covered. It is therefore of the essence to add after the previous item that any future revisions of the original specification are equally included in that promise. Include at beginning of specification and after the previous item all and any Promises or similar references that will ensure the future continuity of the initial Promise for the implementer.  
PT 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.  
PT 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.  
PT 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 labeled version of the Zip format.  
PT 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.  
PT 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.  
PT 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  
PT 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. Clarify what size the thumbnails should be, or that the images are scaled.  
PT 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.  
PT 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.  
PT 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 a user wants his application to produce standards-compliant output? So yes to PNG, no to VML, yes to MathML and SVG? Where can we 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.  
PT 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  
PT 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  
PT Part 1, Section 2.3 line 14 ed Are additional syntactic constraints only normative when they 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.  
PT Part 1, Section 2.3 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.  
PT Part 1, Section 2.4 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.  
PT Part 1, Section 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? Clarify the use of the word “element” perhaps by saying “XML element” if that is what is meant.  
PT Part 1, Section 2.6 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”.  
PT Part 1, Section 2.6 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...”  
PT 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.  
PT 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”?  
PT 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  
PT 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  
PT 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.  
PT 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.  
PT 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...”  
PT Part 1, Section 9.2 page 18, line 8 ed Extra period following “explicit.” Remove extraneous punctuation.  
PT Part 2, Section 1. Scope page 1, lines 9 ed 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). Replace 'guidelines' with 'rules'.  
PT 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.  
PT Part 4, Foreword page vi, 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.  
PT 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 their full names.  
PT Part 4, Section 1.1 WordprocessingML Part Summary page 1, line 5 ed Table row 'Alternative Format Import' is deemed to have no root element and no reference. The value of this row is unclear. Clarify the table purpose.  
PT Part 4, Section 1.2 SpreadsheetML Part Summary page 1, line 6 ed Table row 'Custom Property' is deemed to have no root element and no reference. The value of this row is unclear. Clarify the table purpose.  
PT Part 4, Section 1.5 Shared Part Summary page 3, line 1 ed Eleven table rows are deemed to have no root element and no reference. The value of these rows is unclear. Clarify the table purpose.  
PT 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”. Clarify this contradiction.  
PT 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.  
PT 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.  
PT Part 4, Section 2.15.1.28 pg 1159, lines 6-9 te The described processing steps are not 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.  
PT 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. Either provide a reasonable document type taxonomy, or loosen the type to an xsd:string to allow applications to provide their own.  
PT Part 4

Section 2.15.3.6 and others

  te The emulation (backward compatibility) functions for legacy systems must not be mixed with the specification's functions that reflect the technological state-of-the-art, as per Part 4.

Such a separation will make it easier to understand and implement a current specification considering the methods specified in ECMA 376, without having to worry about the backward compatibility methods that currently appear in the middle of all the other sub-specifications.

Such a separation will also help mitigating the complexity the task of using a current implementation and getting a clearer idea of the methods that have to be implemented to assure backward compatibility in that implementation.

The emulation functions described in the specification (in example 2.15.3.6 – autoSpaceLikeWord95 and others) should be specified individually and put in a new separate part of the standard (e.g., Part 6 – Emulation Methods to Provide For Backward Compatibility), so as to isolate the updated specification from the backward compatibility specification.

This would make the current specification easy, clear and easy to implement for implementers that do not want to have to think about legacy systems. On the other hand, the main specification would become technically 'purer' as the complexity of implementing the emulation methods would be eliminated altogether.

The emulation methods could therefore basically work like an extension to the main specification that an implementer might or not want to use as the extension is part of the global OpenXML specification.

 
PT Part 4

Section 2.15.3.6 and others

  te No technical specification is provided for the implementation of any of the backward compatibility functions mentioned in the previous item and in the ECMA specification 376. All that is provided is basic Guidance.

In example 2.15.3.6, the specification differs from item 2.15.3.5 and is also less detailed.

In addition the guidelines mentioned, the backward compatibility items should also include a corresponding technical description which – even if short – could be used as implementation guidance, so that the implementer won't have to read or study the mentioned external sources in order to reproduce behaviors (e.g., Word 95). More details are provided in the next 11 comments.

In proposed new Part 6 mentioned above, (Part 6 – Emulation Methods to Provide For Backward Compatibility), include for instance the required technical expansion for each item to provide the implementer with the information required to reproduce the original behavior.  
PT 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. Define the intended behavior.  
PT 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. Define the intended behavior.  
PT 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. Define the intended behavior.  
PT 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. Define the intended behavior.  
PT 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. Define the intended behavior.  
PT 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 implementations to specify their preferences? Define this in an application neutral way. If it is truly a Word-only feature, then remove it from OOXML and express as an application-defined extension.  
PT 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. Define the intended behavior.  
PT 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. Define the intended behavior.  
PT 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.  
PT 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. Define the intended behavior.  
PT 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. Define the intended behavior.  
PT 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. Define the intended behavior.  
PT 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'.  
PT Part 4, Section 2.16.5.33 - te This field says that it merely retrieves the picture contained in the named document. Is there 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.  
PT 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.  
PT 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.  
PT 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.  
PT 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 which is allowed here.  
PT Part 4, Section 2.16.5.40 page 1543, line 12&13 te The definition for 'LISTNUM' is built upon the concepts of 'current' or 'specific' or 'next series', which are not defined in this context (a backward search on 'series' shades no light on this). Those concepts should be defined in the text, and their definition should either be copied or referenced in the context of the definition for 'LISTNUM'. Expand or reference the definition for 'series', and/or clarify the definition for 'LISTNUM' by any appropriate means.  
PT Part 4, Section 2.16.5.77 - te The example that illustrates USERINITIALS section shows instead USERNAME. Correct the example.  
PT 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.  
PT 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. Provide full normative definitions for these graphical elements. Also, for informative purposes, these graphics may be provided in standalone file form.  
PT 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.  
PT 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  
PT 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.  
PT 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.  
PT Part 4, Section 2.18.66 “decimalEnclosedFullstop” te The example given does not show enclosed characters and so contradicts the normative text. Reconcile the text and the example.  
PT Part 4, Section 2.18.66 “decimalFullwidth”, etc. te 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 ITF16 encodings, there should be no mention of other encodings. Reconcile the text and the conformance clause..  
PT Part 4, Section 2.18.66 “lowerLetter”, etc. te Several counting systems are defined to use letters of the alphabet, but nothing is mentioned about how counting continues once the letters of the alphabet are exhausted. Clarify the text to explicitly cover this case.  
PT Part 4, Section 2.18.66 “numberInDash”, etc. te Format requires use of “dash” to surround the number, but no indication of which Unicode dash is intended, en-dash, em-dash, hyphen-minus, figure-dash, quotation-dash, etc. Specify the intended dash explicitly.  
PT 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.  
PT 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.  
PT 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.  
PT 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.  
PT Part 4, Section 2.2 Main Document Story page 26, lines 24&27 te These lines define the contents of an OOXML document of type Wordprocessing in terms that are not compatible with the definition of OOXML documents given in Part 1, Section 4. Definitions, page 7, lines 1 to 3. Note that Section 2.2 as a whole is affected by that inconsistency. Rewrite or remove Section 2.2. May consider explaining what a OOXML story would be in terms of documents renditions by applications.  
PT Part 4, Section 2.2 Main Document Story page 26, lines 27&28 te The definition of 'story' is inappropriate. We shouldn't be defining a markup standard in application terms. We should be defining markup in markup terms. Where the user can type is immaterial. Clarify the definition of 'story'.  
PT Part 4, Section 2.2.1 page 28, line 1 te The sentence 'or auto to allow a consumer 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.  
PT 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.  
PT Part 4, Section 2.2.1 background (Document Background) page 27, lines 1&2 te Assuming that background be referring to the background of the document defined by one of its enclosing elements, assuming that the notion of document page and the notion of displaying be properly defined and that their definitions match commonly accepted ones, then the 'This background shall be displayed on all pages of the document, behind all other document content.' sentence makes unclear whether the total surface of a page must be filled with the background, or else how the subpart of the said surface can be determined. Clarify the definition of 'background'.  
PT 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.  
PT Part 4

Section 3.17.4

  te The display of dates is limited the lowest date of 1900, no dates before that can be represented, and dates up to 29 February 1900 are displayed with an error. 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.

There are also two methods for displaying dates (1900 and 1904) that do not help clarifying the specification. 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.

Allow a range of vendor-declared date bases, or explicitly allow negative date serial values to express dates prior to 1900.

Fix date limitations and if there is no other solution, choose to implement ISO 8601 for displaying dates using the Gregorian Calendar. 

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 recommended elsewhere in OOXML for legacy Word features.

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

Adoption of this standard could improve/simplify interoperability with other applications and especially with players in science/scientific research.

It is recommended that this section be specified in  compliance with the W3C MathML standard for displaying maths equations.

It is recommended that OOXML work with 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.

 
PT Part 4

Section 2.15.1.28

  te The specific algorithm for protecting documents does not comply with any known standard.

The hash algorithm provided, is likely based on a legacy algorithm used in Word. 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.

While it is not mandatory to represent this algorithm using another standard one, taking into account the security issues that today obstruct an organization’s everyday operations, a proven security approach should be considered with a proven encryption standard.

Use a standard, FIPS-180 compliant hash algorithm as the default (such as the SHA-256 encryption standard). Legacy hash algorithms should be supported via the described extension mechanism.

Likewise, other algorithms mentioned in the specification and known to be less secure could equally be improved (see next comment).

 
PT Part 4, Section 3.2.29,

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 (such as the SHA-256 encryption standard), as the default. Legacy hash algorithms should be supported via the described extension mechanism.  
PT 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.  
PT 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.  
PT 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.  
PT 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.  
PT 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.  
PT Part 4, Section 3.3.1.69 - te The securityDescriptor attribute, “defines user accounts who may edit this range without providing a password to access the range”. It is a string. But no information is given as to what user accounts are 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.  
PT 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  
PT 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.  
PT 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.  
PT 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.  
PT 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.  
PT Part 4, Section 5.1.12.37 - te Length is said to be “exactly 10 characters”. This is inconsistent with the schema fragment given which defines it as being 10 octets long. Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.  
PT 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.  
PT 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.  
PT Part 4, Section 6.1 page 4343, line 5 ed The relationship of 'Other VML namespaces' to the OOXML proposal is unclear. If the said other namespaces are related to OOXML, clarify the relationship, else remove the reference to them from the text.  
PT 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 this sentence from the text.  
PT Part 4, Section 6.1 page 4343, line 9 ed The reference to the specific commercial product 'Office 2000' brings no value to the proposal. Remove the reference to Office 2000.  
PT 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.  
PT 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.  
PT 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.  
PT 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.  
PT 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.  
PT 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.  
PT 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.  
PT 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.  
PT 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.  
PT Part 4 2.15.2.32, Part 4

6.2.3.17, Part 1 15.2.14,

Part 4, Section 7.4.2.5

  te We should avoid that the proposed standard be, in many ways, platform dependent.

Some behaviors may only be

available on the Windows platform,

and not on Mac, Linux, Unix and

others.

.

It should be guaranteed that there

are no Windows-only features in the proposed standard.

 

MB = Member body (enter the ISO 3166 two-letter country code, and.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 17

ISO electronic balloting commenting template/version 2001-10


Top