Template for comments and secretariat observations | Date: | Document: |
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 |
VE | Part 4, section 3.2.29 - | te | Security issue: 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, 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 additionaly to glbal standards . Legacy hash algorithms should be supported via the described extension mechanism. |
||
VE | All the document | te | Security issue: OOXML allows the inclusion of arbitrary binary blobs of data in ways that could be abused my malicious document authors. | Avoid such a practice | ||
VE | MLRELAXNG. zi |
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 |
||
VE | OfficeOpenX
MLRELAXNG. zi |
ge | This annex was not provided in a
humanlyreadable
format as required by JTC1 Directives 8.3.5 and Annex H |
The annex should be provided in a
humanly
readable, lined-numbered format so it can be referenced and cited. Additionally, an electronic machine readable version can be provided according to Annex H |
||
VE | OfficeOpenX
MLSpreadsheet MLStyles.zip |
ge |
This annex was not provided in a
humanlyreadable
format as required by JTC1 Directives 8.3.5 and Annex H |
The annex should be provided in a
humanly
readable, lined-numbered format so it can be referenced and cited. Additionally, an electronic machine readable version can be provided according to Annex
H |
||
VE | OpenPackag
ingConventi ons- RELAXNG.zi |
ge |
This annex was not provided in a
humanlyreadable
format as required by JTC1 Directives 8.3.5 and Annex H |
The annex should be provided in a
humanly
readable, lined-numbered format so it can be referenced and cited. Additionally, an electronic machine readable version can be provided according to Annex H |
||
VE | Section 7.4.2.5 | stringsAsNull
Pg. 5122 |
te | The usage of null-terminated C- style strings is avoiding XML and will cause the markup to interoperate poorly with XML-based tools. | Rewrite the clause to express this feature in an application and platform independent way. | |
VE | Section 2.15.3 | Pg. 1368 | te | The “Compatibility Settings” are not available to understand how the document is rendered. | The references in the “Compatibility Settings” section should be made to full publicly available information. | |
VE | Section 2.15.3 | Pg. 1368 | te | The “Compatibility Settings” are not available to understand how the document is rendered. | The references in the “Compatibility Settings” section should be made to full publicly available information. | |
VE | All | te | Documentation use Namespace like "urn:schemas.microsoft.com:*". An Ecma standard must not reference company-specific namespaces. This should be replaced by an Ecma namespace. | Rewrite all the documentation using only Ecma namespace. | ||
VE | 3 | page 226, lines 10-14 | te | This section forbit the use of date before 1900 and impose the use of January 1, 1900 or January 1, 1904 as lower limit. This conflict with ISO 8601:2004. | Remove these limitations and rewrite this part to be conformed with ISO 8601:2004 | |
VE | 4 | page vii, line 7, | te | 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 page 1378 lines 12-17). | Rephrase the compatibility goal so as to make it realistic. | |
VE | 4 | page 28, line 0 | te | The reference to the urn:schemas-microsoftcom: vml namespace references VML, which is considered as deprecated (Part 4, page 4343, lines 11&12). A new standard should not contain deprecated parts. | Remove all references to VML from the OOXML text, hence remove the reference to the urn:schemasmicrosoft- com:vml namespace hereh | |
VE | 4 | page 28, line 0 | te | Child elements of background are described using deprecated features only. Accordingly, the background element should either be described in terms of current OOXML elements or deprecated. | Describe the background element in terms of non-deprecated elements or remove it. | |
VE | 4 | 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. | |
VE | 4 | pages 699-706 | te | Numerous elements are not required by the standard, but if omitted lead to "application-defined" default behaviors—a completely unnecessary barrier to interchange between applications (causing the same document with "default" styles to appear completely different in two conforming programs), as opposed to simply defining the defaults in the standard. For example, sections 2.7.4 defines elements to specify default paragraph and run properties (docDefaults, pPr, pPrDefault, rPr, and rPrDefault); if these are omitted "the defaults are therefore application-defined". | Remove all application defined. | |
VE | 4 | - | Te | 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. | |
VE | 4 | 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. | |
VE | 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 I want my application to produce standards-compliant output? So yes to PNG, no to VML, yes to MathML and SVG? I can't seem to 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. | |
VE | Part 4, Section 2.16.5.33 | - | Te | This field says that it merely retrieves the picture contained in the named document. Is 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. | |
VE | 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. | |
VE | 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. | |
VE | Part 4, Section 2.16.5.34 | - | te | This does not define how a document 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 documents are named. | |
VE | 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. | |
VE | 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. | |
VE | Part 4, Section 2.16.5.76 USERADDRESS | page 1570 | te | Defines Caps, FirstCap, Lower, Upper, which is contrary to XML and CSS | Use symbols defined in XML and CSS. | |
VE | Part 4, Section 2.16.5.77 USERINITIALS | pages 1570-1571 | te | The text that describes USERINITIALS instead discusses USERNAME. | Describe USERINITIALS. | |
VE | Part 4, Section 2.16.5.78 USERNAME | page 1571 | te | Defines Caps, FirstCap, Lower, Upper, which is contrary to XML and CSS | Use symbols defined in XML and CSS. | |
VE | Part 4, Section 2.16.5.79 XE | page 1571, line 22 | ed | Full name not defined | Define full name. | |
VE | Part 4, Section 2.18.4 ST_Border (Border Styles) | pages 1631-1681 | te | Border styles is not fully defined (e.g missing height, width, color-depth, orientation). The style basicThinLine describes behavior for horizontal, vertical and corner scenarios but many styles (e.g babyRattle, balloonsHotair, etc) provide no such details. The problem with this is that a single style can be interpreted differently by different vendors/implementors. Also, these styles provide no generality. | Provide full definition for each border styles or drop they. | |
VE | 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, preferably in a scalable graphics format like SVG. | |
VE | Part 4, Section 2.18.4 | - | Te | 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. | |
VE | 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. | |
VE | Part 4, Section 2.18.46 ST_HighlightColor (Text Highlight Colors) | pages 1738-1740 | te | Some colors contradicts the standard SVG Color Keyword Names's hexadecimal RGB values for given color names. | Use SVG Color keyword name's hexadecimal RGB values. | |
VE | Part 4, Section 2.18.51 ST_Lang (Language Reference)_ | page 1747, line 19, | te | OOXML relies upon ISO 639-1:2002 for languages description. ODF 1.0, ISO/IEC 26300:2006 relies upon ISO 639, which is more complete (aka chy) for the same purpose. The use of ISO 3166 only brings a country code, which is not enough to map all existing entries of ISO 639-2:1998 upon ISO 639-1:2002. Moreover, ISO 639-3:2007 was adopted as an ISO standard since 2007-02-05, making an explicit reference to ISO 639-2:1998 problematic. | Replace/complete ISO 639-1:2002 by ISO 639 (as a whole). Would accept two and three letters language codes (instead of two letters code only so far). | |
VE | Part 4, Section 2.18.51 | - | Te | The use of 255 enumerated language codes, in addition to ISO 639-1 codes, adds no expressive value and only increases the work required of any application that would process an OOXML document. | Drop the use of the redundant ST_LangCode | |
VE | 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 | |
VE | Part 4, Section 2.18.52 ST_LangCode (Two Digit Hexadecimal Language Code) | pages 1748-1754 | te | A lot of language codes are missing and representation is in contrast with ISO:639. OOXML precludes as a matter of principle the representation of the majority of the world's languages in document metadata. | Use ISO:639 and ISO:3166 for language code. | |
VE | 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. | |
VE | Part 4, Section 2.18.57 ST_LongHexNumber (Four Digit Hexadecimal Number Value) | page 1759, lines 11-12 | te | In the title there is "four digit" and in the text "eight digit". | Correct with the right value. | |
VE | 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. | |
VE | Part 4, Section 2.18.66 | - | Te | The formatting system described here is not comprehensive, lacking, for example, support for Armenian, Tamil, Greek alphabetic, Ethiopic and Khmer numerations, all in use today, as well as the various historical systems still used by scholars. | Use a more flexible, extensible, generative approach to numeration, such as that used by the W3C's XSLT standard in their xsl:number support | |
VE | Part 4, Section 2.18.66 | - | Te | 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. | |
VE | Part 4, Section 2.18.66 | “chicago” | te | 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. | |
VE | 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. | |
VE | 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.. | |
VE | 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. | |
VE | 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. | |
VE | 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. | |
VE | 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. | |
VE | 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. | |
VE | Part 4, Section 2.18.86 ST_ShortHexNumber (Two Digit Hexadecimal Number Value) | pages 1808-1809 | te | With two hexadecimal digit cannot be represented the 2F6C value in the example. | Use for hexadecimal digit | |
VE | 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. | |
VE | 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. | |
VE | 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. | |
VE | 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. | |
VE | Part 4, Section 3.3.1.61 pageSetup (Page Setup Settings) | pages 1988-1990 | te | Define a "paperSize" attribute whose value is an integer representing one of 68 fixed paper sizes. These paper-size codes are apparently based on corresponding paper-size registry codes in Microsoft Windows, rather than using the standard paper-size names as defined in 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. | Use a standard paper-size specification. | |
VE | Part 4, Section 3.3.1.62 pageSetup (Chart Sheet Page Setup) | pages 1992-1993 | te | Define a "paperSize" attribute whose value is an integer representing one of 68 fixed paper sizes. These paper-size codes are apparently based on corresponding paper-size registry codes in Microsoft Windows, rather than using the standard paper-size names as defined in 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. | Use a standard papaer-size specification. | |
VE | 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. | |
VE | Part 4, Section 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 | |
VE | 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. | |
VE | 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. | |
VE | 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 type that should be used. | Use the ST_HexColorRGB type and remove ST_HexBinary3 | |
VE | 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. | |
VE | 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. | |
VE | 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. | |
VE | 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. | |
VE | Part 4, Section 6.1.2.7 | page 4444, “tableproperties” | Te | This element uses a bitmask to specify VML table properties. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. | Rewrite this subclause to express the feature using XML constructs rather than bitmasks. | |
VE | 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. | |
VE | 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. | |
VE | 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. | |
VE | 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. | |
VE | All | te | Documentation use Namespace like "urn:schemas.microsoft.com:*". An Ecma standard must not reference company-specific namespaces. This should be replaced by an Ecma namespace. | Rewrite all the documentation using only Ecma namespace. |
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 10
ISO electronic balloting commenting template/version 2001-10
|
![]() |
|