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 |
|
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.
|
||
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.
|
||
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.
|
||
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 |
1 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
|
![]() |
|