DOCUMENT ACCOMPANYING THE GREEK VOTE TO

ISO/IEC DIS 29500 

Dear Sirs, 

The Greek National Body (ELOT, Greece) after intense discussions on the OOXML specification finally decided to approve the draft version of ISO/IEC 29500, albeit with extensive comments providing various editorial and technical improvements to the ECMA Standard. 

Before presenting these comments, ELOT would like to forward the following requests to JTC1/SC34 Chairman and Secretary: 

  1. ELOT requests that a ballot resolution group be setup, independently of the result of the voting procedure for ISO/IEC DIS 29500.
  2. The ballot resolution group must be mandated by SC34 to discuss all the comments received during the voting period, independently of the source of the comment (e.g. comments accompanying approval votes should be treated equally to comments accompanying disapproval votes).
  3. ELOT would like to be notified about the structure, meeting date(s), location, Convener, and Project Editor of this ballot resolution group.
 

General comments, accompanying the Greek Vote: 

After intense discussions, we decided to give, through the portion of the decision that belongs to our vote, the proposed Standard a chance to exist. 

This position MUST not be interpreted as a blank check for the text of the Standard. Indeed, we believe that there are numerous areas (especially because it is an immense document) were improvements are necessary to make the document a truly open and useful one for end-users and developers. 

Apart from the normal comments, either technical or editorial, that are presented in the attached annex, we would like to draw your attention to two issues, which have dominated our discussions. 

1. Patents and Patent policy.  

We do not think that comments should address only the text of the Standard itself. This important document will be given to end-users and implementers and they may find themselves tied to various patents, and property rights owned by the company that proposes this Standard. 

While Microsoft, the originator of the document, has promised not to sue implementers of the specification (and this may reflect a good intention of the originator), a large fraction of it is nevertheless covered by patents owned by Microsoft. Since Microsoft still holds these patents and has not done anything to make them legally invalid for Open Source use, it is unclear whether this promise is trustworthy. It is at least not trustworthy enough to build a business on. More than that, Microsoft made its promise on the OOXML version 1.0, leaving anything possible for any future version that may follow in a short time. 

Proposal: Following the patents policy of ISO, together with the expressed intention of Microsoft, a full and clear statement must be issued by Microsoft, according to the ISO procedures, infringing on the affected patents, or even the entire OOXML implementation, under a free reusable license, such as the Lesser GPL (LGPL). This gives implementers the irrevocable right to implement the OOXML specification. As an alternative, Microsoft should offer officially, through ISO, a patent promise, that unambiguously permits open source use, and unambiguously covers the present and all future versions of OOXML. 

2. Correction of inaccuracies. 

It can not be accepted that in the name of backwards compatibility, inaccuracies like those dealing with the 1900 dates, may be allowed to exist in the Standard. There should be provisions to correct them.  

Details and proposals for correction are given in specific comments, in the attached annex. 

These two general comments have to be addressed before the finalization of the Standard. In an attached annex, we present much more comments, derived from national experts. We count on the Ballot Resolution Group to address all these comments. If the Ballot Resolution Group fails to resolve satisfactorily the issues, then ELOT will reconsider its position and may cast a vote of disapproval during the BRG meeting(s) according to article 13.8 of the JTC1 directives, or may even appeal to the final adoption of the Standard. 

Best regards, 
 

Evangelos E. Melagrakis

ELOT, Director

Standardization 


 


 

SPECIFIC COMMENTS FROM ELOT – GREECE to proposed ISO/IEC DIS 29500 

National  Comittee Line number Clause/ Subclause Paragraph / Figure / Table Type of comment  (General/Technical/Editorial Comments Proposed change
GR   Throughout   ge While Microsoft has promised not to sue implementors of the specification, a large fraction of it is nevertheless covered by patents owned by Microsoft. Since Microsoft still holds these patents and has not done anything to make them legally invalid for Open Source use, it is unclear whether this promise is trustworthy. It is at least not trustworthy enough to build a business on. Microsoft to publish an implementation of code infringing on the affected patents, or even their entire OOXML implementation, under a free reusable license, such as the Lesser GPL (LGPL). This gives Open Source and other implementors the irrevokable right to implement the OOXML specification. As an alternative, Microsoft should offer another patent promise, that unambigously permits open source use, and unambiguously covers all future versions of OOXML.
GR   Throughout   ge How has the verification of conformity to OOXML standard proposed to be done and has it been done till today by an independent third party?  
GR   Part 4, Section 3.17.4.1 Page 2522 te OOXML only support two time-bases or date-bases (the 1900 base and the 1904 date). None of those two  reperesent  corrrectly  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
GR   Part 4, Section 3.17.4.1 Page 2522 te OOXML can not represent important dates and  generates wrong  data calculations. 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 used elsewhere in OOXML for legacy Word features.
GR   Part 4, 3.17.4.1   te OOXML specifies that in the year 1900, “for dates between January 1 and February 28, WEEKDAY shall return a value for the day immediately prior to the correct day” and also assigns a “serial value” to the non-existing day February 29, 1900. This is wrong. Software bugs should be fixed, not exported by means of ISO standards to the programs of competitors. Make the calendar system configurable, with a default of the Gregorian calendar, allowing alternatives to be specified by means of providing code for the computation of year, month, weekday and day-of-the-month. .
GR   Part 3 ,  3.16.9                      Part 4, Section 3.17.4.1 Page 2522, lines 15 and 16: te In the 1900 date base system, the lower limit is January 1, 1900, which  has serial value 1. There are people alive today born before 1900.  Historical studies often consider dates before 1900. Remove this restriction and allow  a greater  date  support. Allow negative values in the serial number.
GR   Part 4, Section 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 behavior that results in incorrect date calculations.
GR   Part 3, 3.16.9.1 – 3.16.9.3 
Part 4, 3.17.4.1 3.17.6.7
  te Having two different date systems with different base dates side-by-side in the same standard document format makes no sense. Rather, it is appropriate to fix a single base date. Applications which use a different base date can convert from the date representation used in the standard document format to the application's preferred date representation, and vice versa. Delete all references to the “1904 base date system”.
GR   Part 4, Section 2.8.2.16 - te Use of bit masks is not  the right way in XML. This element of the specification uses a set of bitmasks to specify which code pages a given font supports. The use of bitmasks rather than an XML Schema derived type makes this data almost impossible  to work with standard XML tools like XSLT which lack bit-level operations.  One of the advantages of XML is that we don't need to encode data like this any more. Rewrite this subclause to express the feature using XML constructs rather than bitmasks.
GR   Part 4, Section 7.4.2.4 - te The presence of non-XML characters, escaped, or not escaped in an OOXML document, is contrary to interoperability of XML and XML-based tools.  The W3C's Internationalization Activity confirms this interpretation, saying “Control codes should be replaced with appropriate markup. Since XML provides a standard way of encoding structured data, representing control codes other than as markup would undo the actual advantages of using XML. Use of control codes in HTML and XHTML is never appropriate, since these markup languages are for representing text, not data.” Remove the bstr type from OOXML
GR   Part 1,  introduction (page xii) and entire document   te It is not acceptable for an international standard to be designed primarily around the goal of compatibility with a particular company's products. This is particularly inappropriate where, as in the present case, compatibility with an existing international standard is neglected in favor of the one-sided goal of maximal compatibility with document file formats introduced by one company, and where the proposed standard does not provide equal opportunities for compatibility to that company's present and future competitors. Unless this shortcoming of OOXML/DIS 29500 is fixed, accepting this specification as a national or international standard would be a violation of national and international law. Change the goal from being „fully compatible“ with „existing investments in Microsoft Office documents“ to seeking at attain the same high level of compatibility not only with Microsoft's formats, but also with the international norm ISO/IEC 26300 (OpenDocument). Review the entire draft standard and modify it corresponding to this revised goal.
GR   Part 1, Section 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.
GR   Part 4, Section 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
GR   Part 4, Section 6.1.2.19 pg. 4653 “equationxml” te This describes  the "equationxml" attribute of "shape" elements, "used to rehydrate an equation using the Office Open XML Math syntax". However, the "actual format of the contents of this attribute are application-defined", which makes them impossible to exchange between applications.  If we're going to have  a new math markup language in XML, and ignore the existing MathML,  let's at least use the new markup in its elemental form, as well-formed XML (not stuffed into an attribute value), and without extending it in application-dependent ways. Define equations in an interoperable way.
GR   All 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.
GR   Page 1754 line 1 te Language specification: OOXML is ignoring ISO 639 and 639-2, and instead is using Microsoft Locale ID page Accept using ISO 639 , 639-2 specifications
GR   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
GR   Part 4, 2.18.52   te Having two different language representation systems, one based on ISO standards and one with arbitrary hexcodes for a subset of the languages makes no sense. Applications which use arbitrarily-chosen numeric values to represent some languages can convert from the standard language representation system to the codes they use internally, and vice versa. Delete all references to ST_Langcode.
GR   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.
GR   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.
GR   Part 4, Section 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  additionaly to glbal standards  .  Legacy hash algorithms should be supported via the described extension mechanism.
GR   Part 4, Section 2.15.1.28   te The algorithm given there has not undergone any peer review. Why are they not using a recognized standard cryptographic hash algorithm like SHA-256 or Whirlpool?   Since the algorithm specified has not undergone review, we do not know that it is secure. It can be argued that  most  Office application do not need strong hashing, but   a specification  for standard must have general purpose and  take into account all the situations. It is not clear,   how this feature can accept another hashing alternatives. Using a recognized standard cryptographic hash algorithm like SHA-256, Whirlpool, or so.
GR   Part 4, 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.
GR   Part 4, 3.17.4.3   te The “combined date and time representation” is broken in Spain and all other locales which switch to daylight-saving time and back, on those days which are 23 hours or 25 hours long instead of the usual 24 hours  (summer and winther timeframes) This problem can be easily avoided by always using UTC for the “combined date and time".
GR   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.
GR   Part 4, Section 2.15.1.28 - te This says that document protection “shall be enforced”.  “Shall” indicates required behavior.  But then a few sentences later it says that document protection “may be ignored”.  Clarify this contradiction.
GR   Part 4, Section 2.15.1.28 line 13 te This algorithm description fails to specify the encoding of the input password.  Presumably it is Unicode, but in what encoding?  UTF-16BE?  UTF-16LE?  UTF-16 with a BOM (Byte Ordering Mark)?  The described algorithms make use of byte-level manipulations which depend on the machine architecture (big endian versus little endian).  So it is necessary that all byte ordering assumptions be made explicit. Make the byte ordering assumptions explicit, both for the input password and the processing steps, so as to allow cross-platform interoperability.  Keep in mind that the hash may be calculated on a different machine architecture than the password was entered with.
GR   Part 4, Section 2.15.1.29 - te This element allows the classification of the document into one of three types: “letter”, “email” or “general”.  Although the description says that this feature can be used by, “hosting applications to facilitate customized user interface and/or automatic formatting behaviors based on the 'type' of a given WordprocessingML document”, the taxonomy provided is so weak as to be practically useless. Either provide a reasonable document type taxonomy, or loosen the declared type to an xsd:string to allow applications to provide their own classifications.
GR   Part 4, Section 2.15.1.86 - te This element uses a bitmask to specify a style display filter.  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.
GR   Part 4, Section 2.15.1.87 - te This element uses a bitmask to specify style display sorting parameters.  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.
GR   Part 4, Section 2.15.3.26 - te This is the “footnoteLayoutLikeWW8” element, which is defined in terms of mimicking a legacy application's behavior.  The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
GR   Part 4, Section 2.15.3.31 - te This is the “lineWrapLikeWord6” element, which is defined in terms of mimicking a legacy application's behavior.  The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
GR   Part 4, Section 2.15.3.32 - te This is the “mwSmallCaps” element, which is defined in terms of mimicking a legacy application's behavior.  The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
GR   Part 4, Section 2.15.3.41 - te This is the “shapeLayoutLikeWW8” element, which is defined in terms of mimicking a legacy application's behavior.  The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
GR   Part 4, Section 2.15.3.51 - te This is the “suppressTopSpacingWP” element, which is defined in terms of mimicking a legacy application's behavior.  The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
GR   Part 4, Section 2.15.3.54 - te This is the “ uiCompat97To2003” element, which is defined as: “Disable UI functionality that is not compatible with Word97-2003”. But what use is this if I am using OOXML in OpenOffice or WordPerfect Office? What if I want to disable UI functionality that is not compatible with OpenOffice 1.5? Or WordPerfect 8? Or any other application? Where is the ability for other implementations to specify their preferences? Define this an application neutral way.  If it is truly a Word-only feature, then remove it from OOXML and express as an application-defined extension.
GR   Part 4, Section 2.15.3.54 - te This is the “truncateFontHeightsLikeWP6” element, which is defined in terms of mimicking a legacy application's behavior.  The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
GR   Part 4, Section 2.15.3.6 - te This is the “autoSpaceLikeWord95” element, which is defined in terms of mimicking a legacy application's behavior.  The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
GR   Part 4, Section 2.15.3.63 - te This is the “useWord2002TableStyleRules” element, which is defined in terms of mimicking a legacy application's behavior.  The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
GR   Part 4, Section 2.15.3.64 - te This is the “useWord97LineBreakRules” element, which is defined in terms of mimicking a legacy application's behavior.  The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
GR   Part 4, Section 2.15.3.65 - te This is the “ wpJustification” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
GR   Part 4, Section 2.15.3.66 - te This is the “wpSpaceWidth” element, which is defined in terms of mimicking a legacy application's behavior.The standard contains insufficient detail on how to replicate this behavior. Define the intended behavior.
GR   Part 4, Section 2.16.4.3 page 1501, line 0 te The definition for BATHTEXT references 'the given Thai format', which makes no sense in the context of that definition.  What “given Thai format”? Clarify the definition of 'BATHTEXT'.
GR   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.
GR   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.
GR   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.
GR   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.
GR   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 and Xpath versions which are allowed here.
GR   Part 4, Section 2.16.5.5 page 1512,  
lines 11-12
te According to the text, the AUTONUM field is deprecated. A new standard should not contain deprecated parts. Remove all references to AUTONUM from the OOXML text.
GR   Part 4, Section 2.16.5.77 - te The example that illustrates USERINITIALS section instead shoes  USERNAME. Correct the example..
GR   Part 4, Section 2.18.106 - te Length is said to be “exactly 1 character”.  This is inconsistent with the earlier language and the schema fragment given which defines it as being 1 octet long or two characters. Clarify the definition.  In particular note that xsd:hexBinary measure length in octets, not characters.
GR   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.
GR   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.
GR   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.
GR   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.
GR   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
GR   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.
GR   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.
GR   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.
GR   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.
GR   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.
GR   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.
GR   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.
GR   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.
GR   Part 4, Section 2.2.1 page 28, line 1 te The sentence 'or auto to allow a consumer to automatically determine the background color as appropriate.' does not define the appropriate behavior of the consumer, whereas the definition of the corresponding simple type, found in Part 4, page 1737, explicitly states that 'This value shall be used to specify an automatically determined color value, the meaning of which is interpreted based on the context of the parent XML element.' Define the characteristics of the auto value for the color attribute of the background element properly.
GR   Part 4, Section 2.2.1 page 29, line 0 te There are several instances of the word 'border' that are meaningless in this context (the text is supposed to describe the 'background' element at that location and no “border” has been defined). Clarify which border the text refers to (if any notion of border must be introduced here) or else rewrite the text so that it makes sense.
GR   Part 4, Section 2.2.1 background (Document Background) page 27, lines 8&21 te Contradicting use of accent3 and accent5 – the text says one thing, but the example says another. Fix the contradiction.
GR   Part 4, Section 2.3.1.8 - te This element uses a bitmask to specify various paragraph conditional formatting 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.
GR   Part 4, Section 2.3.3.19 - te 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
GR   Part 4, Section 2.4.51 - te This element uses a bitmask to specify various table style formatting 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.
GR   Part 4, Section 2.4.52 - te This element uses a bitmask to specify various table style formatting exceptions.  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.
GR   Part 4, Section 2.4.7 - te This element uses a bitmask to specify various table cell formatting 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.
GR   Part 4, Section 2.4.8 - te This element uses a bitmasks to specify various table row  formatting 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.
GR   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.
GR   Part 4, Section 3.2.29 p. 1917-1922 te No normative description of the password hashing algorithm is provided, so interoperability of this feature cannot be assumed.  In an informative section, 5-pages of C-language source code is provided as “an example”, and  this appears to involve machine-dependent bit manipulations. Provide a normative, cross-platform definition of the hashing algorithm.  Cross-platform source code can be given as an example, but the normative text should be in English, not in a programming language.
GR   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.
GR   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.
GR   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.
GR   Part 4, Section 3.3.1.61 - te The pageSize attribute allows a set of enumerated values which does not encompass all of the page size values permitted by ISO 216, ANSI Y14.1 and similar DIN and JIS standards. Rather than trying to maintain a paper size registry, a more flexible approach would be to simply record the dimensions of the paper size selected.
GR   Part 4, Section 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.
GR   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.
GR   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.
GR   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.
GR   Part 4, Section 5.1.12.37 - ge Why are there several different definitions for a Panose value, both in Word Processing ML as well as Drawing ML?  Since they are exactly the same they should be defined once in a shared schema.
GR   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.
GR   Part 4, Section 5.1.3.4 - te This describes the attachment of a QuickTime video to a presentation object.  No description of the QuickTime format is provided.  Without specifying a version and supported codecs, there will be no interoperability. Provide an external reference for the version(s) of QuickTime format intended here as well as an interoperable codec.
GR   Part 4, Section 6 - te OOXML specifies here a markup language called Vector Markup Language (VML) which, in addition to DrawingML, specifies a vocabulary for describing graphical objects.  Section 6.1 says, “The DrawingML format is a newer and richer format created with the goal of eventually replacing any uses of VML in the Office Open XML formats. 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”  The need to support VML by OOXML consumers, in addition to DrawingML, would come at great implementation expense (the VML specification is over 600 pages) , would disadvantage all vendors but Microsoft, and would hurt interoperability. Remove VML from OOXML.  Vendors who have access to the legacy binary format documentation, such as Microsoft, are free to convert the VML to the “newer and richer” DrawingML at the same time they convert the document to OOXML.
GR   Part 4, Section 6.1.2.19 pg. 4655, “gfxdata” te Describes a "gfxdata" attribute for the "shape" elements, which "contains DrawingML content" that is "base-64 encoded".  However, the "contents of this package are application-defined", so even though they "shall use the Parts defined by this Standard whenever possible" there is not sufficient information for an independent implementation to read this data or display the "DrawingML content" contained therein.  If we're going to have  a new graphics markup language in XML, and ignore the existing SVG,  let's at least use the new markup in its elemental form, as well-formed XML (not stuffed into an attribute value), and without extending it in application-dependent ways. Define this in an interoperable way.
GR   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.
GR   Part 4, Section 6.4.2.10 - te This element is defined as providing a, “general-use element for objects  that use an image representation, such as OLE objects, embedded controls, cameras and signature lines.”  However, the allowed values, EMF, WMF, etc., refer to formats for which no reference has been given. Provide a proper external normative reference for the allowed formats containable within this element.
GR   Part 4, Section 6.4.3.1 - te The allowed values of this enumeration, EMF, WMF, etc., are Windows-specific formats.  No allowance seems to have been made for use by other operating systems.  For example, in Linux images are typically copied on the clipboard in an open standard format like PNG. Several options here, but the desire is to allow cross platform interoperability.
GR   Part 4, Section 7.1 - te This is the specification of Office Open Math Markup Language, a specialized XML vocabulary for the describing the layout of mathematical equations.  This solves the same problem as MathML, a long-established W3C standard and an ongoing activity in the W3C.  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.
GR   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.
GR   Part 4, Section 2.3.2.8 page 178 te It is desired to have improved interoperability between ODF and OOXML.  However, OOXML's "vert" attribute only allows text to be rotated 270 degrees, whereas ODF's equivalent allows text rotation by 90 or 270 degrees. Include ability to specify 90 degree text rotation in addition to existing 270 degree rotation.
GR   Part 4, Section 2.3.2.1 page 160 te It is desired to have improved interoperability between ODF and OOXML.  However, OOXML text runs only support two font weights, bold or normal, where ODF supports the fuller range of font weights from XSL-FO Include support for additional font weights, 100, 200, 300, 400, 500,600. 700, 800 and 900.
GR   Part 4, Section 2.4.46 page 421 te It is desired to have improved interoperability between ODF and OOXML.  However, OOXML lacks the ability to specify a multi-row header that repeats across pages, where ODF does. Include in this section the ability to specify that the first N rows of a table can be selected as a header.
GR   Part 4, Section 7.4.2.5 - te It doesn't make sense for us to be specifying strings as null-terminated C-style strings and then to base-64 encode that.  That is avoiding XML and will cause the markup to interoperate poorly with XML-based tools. ECMA should rethink the entire Clipboard Data representation.  It looks very much like it is mapping directly to the arbitrary internals of a single application.  This clause should be rewritten to express this feature in an application and platform neutral way.
GR   Part 4, Section 3.17.3 “#DIV/0!” te The “note” for this error value appears to define required behavior, not informative remarks Make the contents of the note be part of the main text, not as a note.
GR   Part 4, Section 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.
GR   Part 4, Section 2.8.2.2 “0xEE” 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”.
GR   Part 4, Section 2.8.2.2   te The default character set is said to be “the ANSI character set”.  But ANSI has standards for many character sets.  Do you mean ANSI 209-1992 “Matrix Character Set for OCR”?  Probably not.  So a normative reference to a specific standard is required. Provide normative reference for “the ANSI character set”.
GR   Part 4, Section 3.17 throughout te Many of the financial functions rely on a “date count basis” value that is not defined in this standard.  Without this level of definition implementors will not be able to evaluate these functions. Provide a full definition of “day count basis”, in particular with respect to treatment of leap years and leap days.
GR   Part 4, Section 3.17.7.4 ACOS te It is not indicated whether the returned value shall be in radians or degrees Specify the angular units that should returned
GR   Part 4, Section 3.17.7.9 AND te It is not specified whether this function short-circuits or not.  In other words, must the remaining arguments be evaluated once one of them is found to be FALSE?  Since some functions have side effects, it is necessary to define this in order to ensure interoperability. Specify whether this function allows short-circuit evaluation.
GR   Part 4, Section 3.17.7.34 CELL te The list of values supported for the “format” argument is far shorter than the list of possible numeric formats. What happens if CELL(“format”, A1) is called on a cell with a format not on this list? Specify what happens in this case.
GR   Part 4, Section 3.17.7.35 CHAR te This function maps between numbers and characters.  But this mapping must be defined b y a character set and none is defined here. Specify what character set is used for this mapping.
GR   Part 4, Section 3.17.7.49 CORREL te The definition of the arguments in the function is incorrect.  It should say that x-bar and y-bar are the sample means, not x and y. Correct the text
GR   Part 4, Section 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.
GR   Part 4, Section 3.17.7.66 CUBEMEMBER te This function refers to, “A multidimensional expression (MDX) that evaluates to a unique member in the cube”.  But MDX is undefined. Define the syntax and semantics of an MDX
GR   Part 4, Section 3.17.7.74 DATE te The definition of date normalization is rather loose.  I think you want to say something like this;  “if month is greater than 12, then month-12 shall be added to the first month in the year specified.”, etc.  The problem with how it is stated is that “that” does not refer to anything in “that number of months”. Clarify the definition of date normalization.
GR   Part 4, Section 3.17.7.76 DATEVALUE te This function says that it can take a string in any valid date and/or time format.  It further says that if the year portion of the input string is ommitted, that the current year is used.  But what if the date is omitted as well, e.g, someone passes in a  pure time string like “10:34”?  Do we assume the current date?  Or assume January 1st of the current year? Resolve the ambiguity in the definition when a string with time format is passed in.
GR   Part 4, Section 3.17.7.77 DAVERAGE te Normative information regarding the processing of “an entire column in a database” is placed in an informative note.  Since it is clearly stating a requirement in the processing this should be in the normative text. Rework the note into the normative description of this function.
GR   Part 4, Section 3.17.7.344 WORKDAY te This function is defined to skip over weekends in its calculations, but weekend is not defined and has different definitions in different parts of the world. Define this function unambiguously and preferably in a way which provides for cultural adaptability in the definition of a weekend.

Top