Comments Date:  31 August 2007 Document: ISO/IEC/JTC1/DIS 29500 OOXML
 
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

IN1 Throughout the document   te OOXML does not support macros and hence does not support backward compatibility as per its design goals OOXML to provide mechanism to support backward compatibility of macros as per its design goals  
IN2 Throughout the document   te OOXML specification is not free from references to particular product OOXML must be free from reference to particular product  
IN3 Throughout the document   te The specification can not be fully implemented by a third party OOXML must ensure that specification should be fully implementable by third party independently  
IN4 Throughout the document   te The document encoding standard is not hundred percent decodable It should be hundred percent decodable  
IN5 Throughout the document   te The OOXML serves the purpose of converting the existing Microsoft owned proprietary documents into an XML serialization. Since the outcome of this will contain elements like "useWord97LineBreakRules", "footnoteLayoutLikeWW8", "autoSpaceLikeWord95" "useWord2002TableStyleRules", etc. === E.g: from file wml.xsd: ===wml.xsd:      <xsd:element name="useWord97LineBreakRules" type="CT_OnOff" minOccurs="0" === wml.xsd:          <xsd:documentation>Emulate Word 6.x/95/97 Footnote Placement</xsd:documentation> === wml.xsd:      <xsd:element name="autoSpaceLikeWord95" type="CT_OnOff" minOccurs="0"> ===wml.xsd:          <xsd:documentation>Emulate Word 95 Full-Width Character Spacing</xsd:documentation> === wml.xsd:      <xsd:element name="useWord2002TableStyleRules" type="CT_OnOff" minOccurs="0"> === Such tags have no value to other vendors other than Microsoft. Such a model therefore is meant to preserve some private namespace, and cannot be called a standard.  The purpose of a standard cannot be to preserve historical blunders. If accepted, this will also create a undesirable precedent in the standardization process. === Therefore this process will not lead to interoperability. 
 
 
 
 
 
 
 
 
 
Add information to define this behaviour  
IN6 Throughout the document   te Need more clarity on the Open Specification Promise of Microsoft which claims it wont assert patent claims against those implementing OOXML. Microsoft to give explicit assurance that it will not assert patent/IPR claim for Microsoft reference necessary to implement  OOXML  
IN7 3.17.4.1   te Ecma 376 section 3.17.4.1, “Date Representation”, conflicts with the Gregorian calendar in the calculation of dates. Specifically, it requires spreadsheet implementations to incorrectly treat the year 1900 as a leap year. This contradicts the Gregorian calendar, ISO 8601 and the civil calendar adopted by most nations of the world. ISO 8601 is the ISO standard for date and time representations. Ecma 376 section 3.17.4.1, “Date Representation” stipulates that dates must be represented as numeric codes counting from 1900 or 1904. This is in conflict with ISO 8601. This section also forbids applications from supporting years before 1900, also in conflict with ISO 8601 Provide support for dates prior to 1900  
IN8 6.2.3.17

6.4.3.1

  te Embedded Objects (Section 6.2.3.17) and Clipboard Format Types (section 6.4.3.1) refer to Windows meta files instead of the ISO standards Such references should be removed  
IN9 7.1   te MathML is the W3C standard for "describing mathematical notation and capturing both its structure and content". Ecma 376 section 7.1 "Math" covers mathematical expressions, and defines a format in conflict and incompatible with the W3C

Recommendation MathML. Note: MathML is included in the ISO/IEC 26300 standard (Open Document Format) in section 12.5 "Mathematical Content". As a result, Ecma 376 conflicts with an ISO specification for mathematical notation.

This issue should be resolved  
IN10 2.15.1.28

3.3.1.69

3.2.29

  te Ecma 376 section 2.15.1.28 does not follow the advice of any of the international organizations. ---Instead, it defines new hashing algorithms that have not undergone scrutiny by the cryptographic community.=== Section 2.15.1.28 defines one; Sections 3.3.1.69 "protected Range" and 3.2.29 define another very similar algorithm. Nowhere is there clear notification that these algorithms are likely to be extremely flawed and thus should not be used in new applications.

This poses two security risks:

===#1 The immediate risk is that hashed document passwords may be determinable from the hashed value. Since users often reuse document passwords for other documents and other systems (whether they should or not), including an inadequately reviewed hash function risks enabling forgery and identity theft of many other systems by attackers.

===#2 Defining a new hash function inside an ISO standard (giving it the ISO seal of approval) creates the expectation that

this hash function has received proper scrutiny by the crytographic community (like ISO 10118-3 has) and is secure. This is likely to lead the industry into using the new insecure hash function(s) in a variety of security-critical applications,

making many other security-critical applications directly vulnerable as well.

Add a line of explanatory text to clarify that weaker hashing algorithm should be used only for backward compatibility  
IN11 2.3.2.36

3.4.11

2.3.1.4

4.3.2.11

4.4.1.33

4.8.13

 
    te
The w:sz element is an example of major internal inconsistencies in the specifications measurements:

=== For fonts, the w:sz element specifies the size in half points (2.3.2.36).

===For frameset, the w:sz element has a string value that could be a relative value, a percentage, or a number of pixels (2.15.2.39). The examples do not refer to w:sz at all.

=== However, as the child of rPr (3.4.11), its value is in points. === Note that in the Spreadsheet section (section 3), none of the

examples have any namespace prefixes.

=== The w:sz attribute is also internally inconsistent:

=== For table borders, the w:sz attribute is specified in eighths of a point, unless the border styleis an art border, in which case the width is in points (2.3.1.4).

=== When used as an attribute of restoredLeft (4.3.2.11), it specifies the size of a dimension in normal view as a percentage of the screen.

=== In presentations, as an attribute of the ph element (4.4.1.33), it is an enumerated value with choices "full", "half", and "quarter" (4.8.13).

=== When sz is used as an attribute of defRPr (default character properties (5.1.5.3.2), it is the size of a font in hundredths of a point.

=== Such inconsistencies dramatically increase the complexity of implementing the specification. All measurement specifications should be evaluated and adapted as necessary to provide a coherent system of measurements applied throughout the specification consistently to minimize the number of inconsistencies.

Remove the inconsistencies  
IN12 Throughout the document   te Ecma 376 shows inconsistent use of the percentages in certain sections of OpenML specification. Remove the inconsistencies  
IN13 2.18.52   te Ecma 376 uses confusing and inconsistent definitions of values with hexadecimal numbers. For example, section 2.18.52, ST_LangCode, is defined on the text as a "two digit hexadecimal code". But the values given cannot be represented by only two hexadecimal digits, but needs four.

=== This is very likely to cause serious confusion in developers trying to implement Ecma 376. However, in other places (such as the definition for ST_LongHexNumber), it notes that 4 octets can store 8 hexadecimal digits (which is correct), so it is not simply a

matter of defining "digit" oddly. This problem also suggests a lack of review, since clearly 4-digit values cannot fit in fields where only 2 digits are permitted. More examples: Attribute Page Spec

says ST_ShortHexNumber 2591 "two octet hexadecimal number" ST_LongHexNumber 2542 "four octet (eight digit) hexadecimal number" ST_LangCode 2531 "two digit hexadecimal code"

It appears an extra sentence of explanatory text is required for section 2.18.52 of the spec. This simple type is rarely used, as the preferred use as defined in section 2.18.51 in the spec is ISO 639-1plus ISO 3166-1alpha-2. === The general comment on hexadecimal documentation does not seem valid however. In all

uses of the ST_ShortHexNumber and ST_LongHexNumber examples are used that makes the use very clear.

 
IN14 6.2.3.23   te Section 6.2.3.23 Attribute "href" (Hyperlink Target) uses a

Namespace "urn:schemas.microsoft.com:office:office".

=== An Ecma standard must not reference company-specific

namespaces.

Alternate solutions for future reference for new developers should be given.  
IN15 3.3.1.61

3.3.1.62

  te Nonstandard, inflexible paper-size naming Sections 3.3.1.61 and 3.3.1.62, both of which involve printer settings, define a "paperSize" attribute whose value is an integer representing one of 68 fixed paper sizes. These papersize codes are apparently based on corresponding [http://support.microsoft.com/kb/135639

paper-size registry codes] in Microsoft Windows, rather than using the standard paper-size names as defined in [http://en.wikipedia.org/wiki/Paper_size ISO 216, ANSI Y14.1, and similar standards]. In contrast, ISO 26300 employs a much more flexible scheme: it simply describes the paper size by recording the physical width and height of the page, leaving the assignment of symbolic paper-size names to the user interface.

Should be resolved  
IN16 6.2.3.17   te Undisclosed proprietary specifications Section 6.2.3.17 "Embedded Object Alternate Image Requests Types requires implementors to support the proprietary Windows Metafiles. Such reference should be removed  
IN17 Throughout the document   te the WordProcessingML part of OOXML lists a large number of “Compatibility Settings”4 which provide Microsoft the ability to store information related to various behaviors from their legacy

applications. These settings have names like: “footnoteLayoutLikeWW8”, “autoSpaceLikeWord95” and “useWord97LineBreakRules.”5 However, the OOXML specification merely lists the names of these settings. It does not define them. Microsoft alone knows what these settings mean, but it declines to give a precise definition of them. This clearly is not precise and certainly does not provide for repeatable or common practice of these features.

Define these settings  
IN18 Throughout the document   te the WordProcessingML part of OOXML lists a large number of list styles representing various different writing systems, language and business conventions.7 These are given names

such as “chicago”, “ideographDigital”, “ideographLegalTraditional”, koreanDigital2” and “koreanLegal”.

These are merely labels, and again, are not precisely defined . The would-be implementors of the OOXML specification are told that something called “Korean Legal Numbering” exists, but they are not told what it means or how to practice it in their application

Define these settings  
IN19 Throughout the document   te Industry records its best practices through standardization. The existing body of document and markup standards represents a compendium of reviewed, approved, and implemented best practices. The work of the Word Wide Web Consortium (W3C)9 is especially relevant to XML document formats, since they maintain the core XML standard as well as related standards such as XHTML, CSS2, XSL, XPath, XForms, SVG, MathML and SOAP, the standards that represent the very backbone of XML and XML related technologies.

=== OOXML, however, incorporates very little of the consolidated best practices of the industry. Worse, would-be implementers of OOXML are asked to use Microsoft's proprietary, legacy formats, even when relevant and superior W3C standards are at hand.

Use of existing standards preferable  
IN20 Throughout the document   te OOXML defines a ST_CF type21, which records the allowed clipboard formats which may be used with a graphical object. The allowed values of this type, EMF, WMF, etc., are all proprietary Windows formats. No allowance has 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. But if a vendor encodes “PNG” into a document record of this type, the document will be invalid, and the document and the application will not conform to the OOXML specification. Necessary corrections to be made  
IN21 Throughout the document   te The “optimizeForBrowser” element of WordProcessingML 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 in OOXML requires that “all settings which are not compatible with the target web browser shall be disabled.” What if I want my application to produce standards-compliant output? So yes to PNG, no to VML, yes to

MathML and SVG? A would-be implementor is not able to specify this with the way OOXML has been designed.

Enhance support for W3C supported browser  
IN22 Throughout the document   te The “Slide Synchronization Properties” feature of DrawingML. provides the ability for presentation to synchronize slide content with centrally-stored slides on a server. This is a feature of Microsoft PowerPoint and SharePoint. However, the description of this feature in OOXML lacks sufficient details. What is the communication protocol? What is the data model? Although standards exist for describing a client-server protocol of this sort, namely the various Web Services standards, OOXML gives no information. Independent interoperable implementations of this function are prevented and the one implementation that exists will be tied to SharePoint. Necessary details to be provided  
IN23 Throughout the document   te An example of a concern is the spreadsheet function NETWORKDAYS(). This function is defined by OOXML to return the number of working days between two dates, exclusive of any

weekends in that interval. For some cultures, the weekend is Saturday and Sunday. For others, the days of rest are either Thursday/Friday or Friday/Saturday. OOXML does not define “weekend” and does not provide a way for the user to define it either. As implemented in Excel the function assumes the weekend is always Saturday/Sunday. This spreadsheet function is defined in a way which renders an incorrect answer for potentially billions of people across the globe. OOXML lacks cultural adaptability.

=== Compare this to the same function in OpenDocument Format, where the user may pass in an additional parameter to override the default definition of a weekend.

=== This is in clear violation of ISO/IEC JTC1 Directives, 5th Edition, Version 3.0, Section 1.2 which says: “A purpose of IT

standardization is to ensure that products available in the marketplace have characteristics of interoperability, portability and cultural and linguistic adaptability."

Resolve the issue  
IN24 Throughout the document   te WordProcessingML defines a number of numeration styles for numbered lists. These numeration styles were essentially only labeled, but not defined. These styles are also defined as a closed list, again matching what Microsoft Word supports, but they are not extensible by other vendors. However, the list of styles provided is incomplete, lacking, for example, support for Armenian, Tamil, Greek alphabetic, Ethiopic and Khmer numerations, as well as the larger number of historic systems used by scholars. The preferred solution is to use a declarative/generative approach, such as used by the W3C's XSL:FO and OpenDocument Format. This allows an open-ended list of numeration styles to be used, each self-defining. Support for extending list of styles be provided  
IN25 11.3.1   te The "compatibility with legacy formats" can only be implemented by Microsoft As indicated, Ecma 376 requires implementors to emulate the behaviour of previous Microsoft products. As the

behaviour is not specified, and the products are proprietary, only Microsoft can implement those portions of the specification.

=== Ecma 376 requires implementors to support Windows Metafiles instead of ISO 8632. As Windows Metafiles are a proprietary technology, only Microsoft can implement this portion of the specification reliably.

=== Ecma 376 section 11.3.1 "Alternative Format Import Part" allows implementations to insert content in alternate file formats such as RTF. RTF is a Microsoft proprietary format. Microsoft can support old binary documents simply by embedding the RTF content. But other implementers cannot reliably support those

documents because the specification for RTF is not included in Ecma 376.

Such reference should be removed  
IN26 2.15.1.28   te Part 4, Section 2.15.1.28 - A hash algorithm is provided, 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.

Use a standard, FIPS-180 compliant hash algorithm as the default. Legacy hash algorithms should be supported via the described extension mechanism.  
IN27 2.15.2.32   te Part 4, Section 2.15.2.32 - This feature has  been defined in a way which ignores the existence of current browsers other than

Internet Explorer. What about Firefox? What about Safari? What about Opera? None of these can be set as target browsers. This section requires that “all settings which are not compatible with

the target web browser shall be disabled.” But what if I want my

application to produce standards compliant output? So yes to PNG, no to VML, yes to MathML and SVG? 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.  
IN28 2.15.3.26   te Part 4, Section 2.15.3.26 - 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.  
IN29 2.15.3.31   te Part 4, Section 2.15.3.31 - 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.  
IN30 2.15.3.32   te Part 4, Section 2.15.3.32 - 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.  
IN31 2.15.3.41   te Part 4, Section 2.15.3.41 - 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.  
IN32 2.15.3.51   te Part 4, Section 2.15.3.51 - 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.  
IN33 2.15.3.54   te Part 4, Section 2.15.3.54 - 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 an application neutral way. If it is truly a Word-only feature, then remove it from OOXML and express as an application-defined extension.  
IN34 2.15.3.54   te Part 4, Section 2.15.3.54 - 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.  
IN35 2.15.3.6   te Part 4, Section 2.15.3.6 - 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.  
IN36 2.15.3.63   te Part 4, Section 2.15.3.63 - 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.  
IN37 2.15.3.64   te Part 4, Section 2.15.3.64 - 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.  
IN38 2.15.3.65   te Part 4, Section 2.15.3.65 - 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.  
IN39 2.15.3.66   te Part 4, Section 2.15.3.66 - 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.  
IN40 2.16.5.41   te Part 4, Section 2.16.5.41 - This describes a “MACROBUTTON” field which can run a designated macro or command. But there is no mention of what programming language or API's are allowed for such a designated macro or command. Described this feature to a level where crossplatform,

crossapplication interoperability is possible. 
 

 
 
IN41 2.18.4   te Part 4, Section 2.18.4 - No mechanism for expanding the set of art borders is provided.  Since the specified art borders are heavily Western-oriented, it would be good to provide a way for an application to supplement these styles with graphics that provide more regional flavor. Provide an interoperable extensibility mechanism for a document author or application to specify their own art border graphics.  
IN42 2.18.66   te Part 4, Section 2.18.66 - There is nothing in this section which is normatively defined except some enumeration values. No normative meanings to these values are given. An informative

example is insufficient in all but the most trivial cases. For example, where is “Korean Legal Counting System” defined?

Give explicit definitions of these numbering styles or proper external normative references.  
IN43 2.18.66   te Part 4, Section 2.18.66 “Chicago” - Format is defined in reference to the “Chicago Manual of Style”, but no edition or page reference is provided. Either include the entire definition in the standard, or provide a proper external reference.  
IN44  
2.18.66
  te Part 4, Section 2.18.66 “decimalFullwidth”, etc. - There are several mentions of double-byte and single-byte Arabic numbering schemes. Since the conformance clause for OOXML requires the use of Unicode in UTF8 or ITF16 encodings, there should be no mention of other encodings. Reconcile the text and the conformance clause.  
IN45 2.18.86   te Part 4, Section 2.18.86 - 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.  
IN46 2.2

Main Document Story Lines 27 & 28

  ed Part 4, Section 2.2 Main Document Story Lines 27 & 28, 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'.  
IN47 2.2.1 Line 0,   ed Part 4, Section 2.2.1 Line 0 - 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.  
IN48 2.2.1 Lines 1 & 2   te Part 4, Section 2.2.1 background (Document Background) Lines 1 & 2, - Contradicting use of accent3 and accent5 – the text says one thing, but the example says another. Fix the contradiction.  
IN49 2.3.3.19

8.2.6

  te Part 4, Section 2.3.3.19 - This says that “The layout properties of this embedded object are specified using the VML syntax”.  However, in Part 1, Section 8.2.6 says, “VML should be considered a deprecated format included in Office Open XML for legacy reasons only and new applications that need a file format for drawings are strongly encouraged to use preferentially DrawingML”   Certainly a new document creating an OLE embedding should not be using VML.  Otherwise, all OOXML consumers will need to support VML, even where legacy documents are not present. Define layout properties of embedded objects using DrawingML rather than VML  
IN50 Foreword

Part 1

  ge This document is not listed as part of the Ecma 376 standard in the Foreword to Part I “Fundamentals” and its status whether informative or normative is not explicitly stated. Clarify the status of this Overview document.  If it is merely a promotional whitepaper about Ecma 376, then it should not be included in the published standard.  
IN51 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.  
IN52 Part 1, Foreword   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.  
IN53 Print Settings   te It is unsatisfactory to store printer settings in OS-dependent binary formats like DEVMODE structures.  This is a considerable security concern (DEVMODE structures are loaded directly into device driver memory), as well as lacking cross-platform adaptability.  There is also no interoperability with print settings as currently defined. Alternatives are available for expressing print settings in XML rather than in binary.  For example, Microsoft's own XPS specification defines a PrintTicket markup for which the XPS specifications says,  “The PrintTicket is XML that provides print settings in a consistent, accessible, and extensible manner. We would like the same qualities in OOXML's print settings, not a binary blob.  
IN54 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.  
IN55 Part 4, Foreword page vi, line 9 ge Explicitly references annexes that are not provided in a humanly-readable format, whereas a human-readable format is required by JTC1 Directives 8.3.5 and Annex H Annexes should be provided in a humanly readable, lined-numbered format so it can be referenced and cited.  The reference to electronic form only annexes should be removed.  
IN56 Part 4, Introduction page vii, line 7 ed Full compatibility of the proposed OOXML with any existing application is demonstrably unreachable (because the proposed OOXML explicitly gives up describing parts of what it aims to describe, e.g. Part 4). Rephrase the compatibility goal so as to make it realistic.  
IN57 3.17.4.1   te The restriction to only two date bases is arbitrary and based only on one vendor's applications.  There are other reasonable values for date bases, including earlier ones for historical dates. Allow a range of vendor-declared date bases, or explicitly allow negative date serial values to express dates prior to 1900  
IN58 3.17.4.1   te The mandated incorrect date calculations for 1900 in the 1900-based date basis is unacceptable.  An ISO standard should not be mandating incorrect values for the well-established Gregorian Calendar.  To do so will only lead to confusion, poor interoperability and perpetuation of errors. If needed for legacy reasons with legacy Excel documents, then introduce an additional vendor-specific tag such as “doWrongDateCalculationsLikeExcel” or similar.  This is the approach recommended elsewhere in OOXML for legacy Word features.  
IN59 3.17.4.1   te The text proposes a dual date base system. There is no clear advantage to having two slightly different systems, and this brings significant costs and confusion, as illustrated by the need to specify a default base system, etc. Choose and keep a single date system.  
IN60 3.17.4.1   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.  
IN61 3.17.4.1   te The proposed date system does not cope with dates prior to 1900-01-01. Propose a better date system.  
IN62 3.17.7.341   te As written this function mandates an incorrect calculation for day of week for certain dates in the year 1900.   An ISO standard should not be mandating incorrect values for the well-established Gregorian Calendar.  To do so will only lead to confusion, poor interoperability and perpetuation of errors. Remove the text that defines behaviour that results in incorrect date calculations.  
IN63 3.2.29-   te A hash algorithm is provided, likely based on a legacy algorithm used in Excel.  This legacy algorithm is known to be a weak algorithm and has effectively been cracked.  One could argue that no hash algorithm would be effective in OOXML, since a user could simply unzip the document and hand edit the XML to remove the hash or to set it to some known value.  However, some application types such as online editing via Google Docs, or other similar applications, can secure physical access to the document via other means.  Editing access to the document does not necessarily presuppose physical access to the document's XML.  So there is a necessity for a secure & interoperable hash algorithm, such as SHA-256 for document protection. Use a standard, FIPS-180 compliant hash algorithm as the default.  Legacy hash algorithms should be supported via the described extension mechanism.  
 
IN64
3.2.29   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.  
 
IN65
3.3.1.69   te No normative description of the password hashing algorithm is provided, so interoperability of this feature cannot be assumed.  In an informative section, C-language source code is provided as “an example”, and this appears to involve machine-dependent bit manipulations. Provide a normative, cross-platform definition of the hashing algorithm.  Cross-platform source code can be given as an example, but the normative text should be in English, not in a programming language.  
IN66 6.1   ed The reference to 'millions of documents' is an unsupported assertion. Furthermore, it is irrelevant in the context of a standard proposal. Remove the marketing fluff from the text.  
IN67 7.1   te This is the specification of Office Open Math Markup Language, a specialized XML vocabulary for the describing the layout of mathematical equations.  This solves the same problem as MathML, a long-established W3C standard and an ongoing activity in the W3C.  Since the equation editing feature of Word was entirely rewritten in Word 2007, there doesn't not seem to be the argument that an additional equation language must be introduced for the sake of legacy documents. It is recommended that this section be removed from OOXML and that the proposers of OOXML work within the W3C's MathML activity, where MathML 3.0 is currently being drafted, to produce a single standard for equations that can be used later referenced by a future version of OOXML.  
IN68 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.  
IN69 Throughout the document   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. Change the name of Office Open XML to a name which is not confused with OpenOffice.  
IN70 Throughout the document   te The MS-OOXML spec contains patented elements in a way not conforming the "ISO/IEC Directives (part 1, section 2.14 ) . Using patents  is compatible with ISO procedures,  but must  follow the ISO/IEC  directives (Part1, section 2.14),  and this   does not happen:  because  some patented funtionalities  are outside the OOXML specification,  some optional funtionalities not covered by the OOXML specification have also patents,  and, finally,  the statment about patents  in OOXML specification is  so vague than it has no legal  security for  companies implementing eventually  OOXML specification. Follow ISO/IEC Directives (part1, section 2.14) for patents issue. The OSP explictly applies to the Ecma 376 version of OOXML, not to the JTC1 DIS 29500 version, or to a version edited at the Ballot Resolution Meeting, or to an ISO version, if approved.  
IN71 3.17.6.7   te This calls for the date serial number to be stored, “as accurately as possible”. This requirement is not precise and is untestable. Further, “as accurately as possible” may entail the use of codes such as arbitrary precision arithmetic, etc. which would have large performance penalties. State the minimum precision required  
IN72 2.8.2.2   te This value is said to signify “an Eastern European character set”. There is no such thing. First, “Eastern Europe” is not unambiguously delineated. Second, this region uses many character scripts, including Roman, Cyrillic, Arabic, Armenian, etc. Explain what is meant by, “an Eastern European character set”.  
IN73 3.17.7.4

3.17.7.12

3.17.7.14

3.17.7.15

ACOS ASIN ATAN ATAN2 te It is not indicated whether the returned value shall be in radians or degrees Specify the angular units that should returned  
IN74 3.17.4.2         3.17.6.7   te In the internet age, it is inappropriate to represent times simply as a numeric value without timezone information. Specify that when stored in OOXML files, dates and times are always expressed in terms of UTC. Add a mechanism for storing in the file information on what timezone should be used to represent the time in human-readable form.  
IN75 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.  
IN76 2.15.3.26

2.15.3.31

2.15.3.32

2.15.3.41

2.15.3.51

2.15.3.54 2.15.3.54 2.15.3.6 2.15.3.63 2.15.3.64 2.15.3.65 2.15.3.66

  te Element, which is defined in terms of mimicking a legacy application's behavior.  The standard contains insufficient detail on how to replicate this behavior. The request was that the text of the standard should enlighten the rest of the world as to what exactly this setting does. The definition should be explicitly highlighted in DIS document.  
IN77 
3.2.29   te A hash algorithm is provided to  secure  passwords, 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, such ISO/IEC 10118-3:2004,  compliant hash algorithm as the default.   Other country specific  standards could be acceptable  such  as  FIPS-180 from NIST,  but  additionally to global standards  .  Legacy hash algorithms should be supported via the described extension mechanism. where this is no provision given for standard, secure algorithms.  
IN78 7.1   te OOXML  is not compatible with the industry standard language for displaying mathematical equations — MathML — used  by  the research community  and the most important publications as Science, Nature, etc... . No interoperability with  MathML   is  in the OOXML specifications. Add  the pertinent  interoperability with MathML. Please note that XML is not an ISO standard either, but no one is complaining that we're using it.  The family of XML-related standards are primarily W3C standards, and are directly relevant to OOXML.


We reject the argument that compatibility reasons with existing documents requires the use of a different math markup language. Microsoft rewrote their equation editor in Office 2007, so the new format used by OOXML actually breaks compatibility with legacy documents.  It does not maintain compatibility.  This is why Science and Nature journals have rejected OOOXML and Office 2007 for paper submissions.

 
IN79 15.2.14   te Security hole.  OOXML allows the inclusion of arbitrary binary blobs of data in ways that could be abused my malicious document authors. For example: Part 1, Section 15.2.14 recommends that print settings be stored in the binary DEVMODE format used by Windows printer drivers.  However, if someone were to change this DEVMODE binary data it would be loaded into the printer driver the next time a user tried to print.  Since a printer driver operates at a higher level of privilege than a user, this may allow a hacker to take control of a user's machine by crafting a specific document.  The current procedure could be a good approach to keep interoperability with past legacy tools, but an ISO standard must provide a clear specification for future implementations which does not perpetuate a security hole. The DEVMODE structure, which is recommended here by example, stores such print settings as page orientation, paper size, paper length, paper width, number of copies, print quality, duplex and collation settings, etc.  This should be stored in XML, not in some undefined application-dependent format.


Further, the security of the system is directly impacted by the number of undefined binary blobs that a document contains.  Look at the historical problems with WMF files, with Word macro viruses etc.

 
IN80 3.16.9   te OOXML only support  two  time-bases or date-bases (the 1900 base and the 1904 date).  None of those two represent  correctly  the Gregorian Calendar (ISO 8601) accepted  in all the world. Also, the restriction to only two date bases is arbitrary and based only on one vendor's applications.  There are other reasonable values for date bases, including earlier ones for historical dates.  Most SQL databases, which frequently exchange data with spreadsheets, support a much greater range of dates. Allow a range of vendor-declared date bases, or explicitly allow negative date serial values to express dates prior to 1900. Our concern remains that the file format does not allow dates before 1900.  Microsoft is certainly entitled to produce a product (Excel) that calculates dates incorrectly and does not allow the specification of dates before 1900.  But this should not prevent other vendors from using OOXML to specify a wider range of dates and to express them correctly. 
 
As defined today, OOXML allows dates from 1900 to 9999.  So, it allows dates only 100 years into the past, but allows dates 7,000 years into the future.  How is that beneficial to anyone?  There are people alive today, living in India, receiving health care, pensions, housing allowances,  etc., who were born before 1900. Their date of birth cannot be represented in the spreadsheet format defined by DIS 29500. There are land records available in the country that are more than 400 yrs old and cant be represented in this format.  This makes OOXML inapplicable for several sectors of the economy, including healthcare.


We should also note that several vendors who have expressed interest in implementing OOXML have products that allow dates earlier than 1900.  For example Novell's version of OpenOffice allows dates back to 1AD.  And Corel's QuattroPro allows dates back to 1835.  (OpenOffice also calculates leap years correctly in 1900).  So for these reasons, we believe that we must raise concerns over OOXML's treatment of spreadsheet dates.

 
IN81 3.17.7.65 CUBEKPIMEMBER te The definition of this function says that it retrieves an OLAP Cube from a “SQL Server”. Surely this function is not limited to use only against Microsoft database servers? Provide a vendor-neutral definition of this function.  
IN82 4.4.1.46   te Wheel (Wheel Slide Transition) (similarly for blind, checker, circle, comb. Cover, cut etc.) - This representation is not enough for an open format. It is desired to have the specifications which help to map to the legacy formats  

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 16

ISO electronic balloting commenting template/version 2001-10


Top