Regular readers will be aware that OOXML, the Microsoft Office XML-based formats adopted by Ecma, are now in the adoption queue at ISO/IEC.  Ecma is a "Class A Liaison" partner with ISO/IEC, which permits it to use the same Fast Track process that national standards bodies use.  That process takes six months -  the same amount of time that the PAS process takes (the route used by OASIS to submit ODF to ISO/IEC) – but has two steps rather than one, although the practical result is much the same.

During the first one-month step, any member may submit "contradictions," which, loosely defined, means aspects in which a proposed standard conflicts with already adopted ISO/IEC standards and Directives.  Those contradictions must then be "resolved" (which does not necessarily mean eliminated), and these resolutions are then presented back to the members during the second stage to consider as part of the voting package.  During this second, five-month step, other objections, questions and comments can be offered by members. (For more detail on the rules relating to contradictions and what can be raised during this phase, see the excellent writeup at the OpenDocument Fellowship site.)

While the unprecedented size of OOXML (over 6,000 pages) has made performing a detailed review a daunting task, more and more contradictions are being found by those that are slogging their way through on this very tight timeframe.  Here is a sampling of those that people have brought to my attention:

Starting with the somewhat silly, OOXML does not conform to ISO 8601:2004 "Representation of Dates and Times."  Instead, OOXML section 3.17.4.1, "Date Representation," on page 3305, requires that implementations replicate a Microsoft bug that dictates that 1900 is a leap year, which in fact it isn't.  Similarly, in order to comply with OOXML, your product would be required to use the WEEKDAY() spreadsheet function, and therefore assign incorrect dates to some days of the week, and also miscalculate the number of days between certain dates.

 

More substantively in the contradiction department, OOXML does not follow ISO 639 "Codes for the Representation of Names and Languages."  That standard defines a list of codes that are maintained by a Registration Authority charged with keeping the list current as ethno-linguistic changes evolve.  Instead, section 2.18.52, "ST_LangCode (Two Digit Hexadecimal Language Code)" (page 2531) says that you must use a fixed list of numeric language codes rather than the already existing set that provide for interoperability among other standards-compliant products – a not unimportant factor in a text standard.

Updated 9-29-07: Peter Constable, the Project Editor of ISO 639-3, contacted me to say that the statement above is inaccurate, stating in part that OOXML, "happens also to allow for a set of integer identifiers defined by Microsoft, provided for backward compatibility with existing documents, but that does not contradict its usage of ISO 639," and requesting that I correct the record. I then checked with my original source, who responded as follows:

I'd direct Mr. Constable to DIS 29500, Part 4, Section 2.16.5.35 (page 1540). The definition of the "/z" field argument says "The text in this switch's field-argument is specifies the language ID used to generate the index as defined in the ST_LangCode (§2.18.52) simple type." If he further references 2.18.52 he will see that ST_LangCode in no way uses ISO 639 language codes. However, it should be noted that there are other sections in OOXML where ISO 639 codes are allowed, but as the above example demonstrates, there is at least one place where OOXML permits only the non-standard Microsoft codes, in contradiction of the existing ISO standard for language codes.

It therefore appears that my statement was both right and wrong on this point, and that OOXML is both compliant in some sections, but not compliant in at least one section. End Update

Similarly, 6.2.3.17 "Embedded Object Alternate Image Requests Types (page 5679) and section 6.4.3.1 "Clipboard Format Types" (page 5738) refer back to Windows Metafiles or Enhanced Metafiles – each of which are proprietary formats that have hard-coded dependencies on the Windows operating system itself.  OOXML should instead have referenced ISO/IEC 8632 "Computer Graphics Metafile" – a platform neutral standard.

Taking the external reference issue further, I'm told that parts of OOXML can't be implemented by your typical programmer at all without technical assistance from Microsoft, as they refer not only to proprietary Microsoft products, but to undocumented parts of them as well – which violates the General Principles of ISO/IEC Directives, Part 2.  Consider the following, from section 2.15.3.26 (page 2199):

2.15.3.26 footnoteLayoutLikeWW8 (Emulate Word 6.x/95/97 Footnote Placement)

This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 6.x/95/97) when determining the placement of the contents of footnotes relative to the page on which the footnote reference occurs. This emulation typically involves some and/or all of the footnote being inappropriately placed on the page following the footnote reference.

[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application. end guidance]

Typically, applications shall not perform this compatibility. This element, when present with a val attribute value of true (or equivalent), specifies that applications shall attempt to mimic that existing word processing application in this regard.

[Example: Consider a WordprocessingML document with a series of footnotes.

If this compatibility setting is turned on:

Then applications should mimic the behavior of Microsoft Word 6.x/95/97 when determining the placement of those footnotes on the displayed page, as needed. end example]

Other parts of OOXML refer to OLE, macros/scripts, encryption and DRM – none of which are fully described.  Nor has Microsoft stated whether necessary information will be supplied on a non-discriminatory basis to all (or at all).

And taking that concern a step further, consider the fact that OOXML also apparently violates section 2.14 of the ISO/IEC Directives, Part 1, in that not all of what it takes to implement OOXML appears to be covered by Microsoft's patent pledge, in two respects.

First, the pledge does not explicitly cover material that is referenced, but not included in the specification, and second, the Microsoft patent commitment does not cover optional features.   Sections of OOXML that are not fully described include those that require compliant implementations to mimic the behavior of Microsoft products, such as those products and capabilities referred to above (OLE, etc.)  Microsoft will need to clarify whether its patent commitment will in fact extend to these requirements.  Potentially, these concerns would involve large portions of OOXML, in contradiction of the ISO/IEC requirement that more than a bare-bones implementation must be permitted without fear of infringement.

All in all, as the waitress in the Monty Python vignette would doubtless have observed (if contradictions were rats), "Rather a lot, actually."  

As the February 5 deadline for report ing contradictions approaches, I expect that you'll be hearing of many more examples such as these.  Eventually, they will all become publicly available, along with the proposed resolutions.  Some, such as the patent pledge ambiguities, are clearly addressable by Microsoft if it wishes to address them.

Other contradictions would seem to be impossible to resolve given the nature of OOXML itself, the stated purpose of which is to describe a single vendor's product – bugs, rats and all.

Updated: Pamela Jones and her crew have set up two very impressive pages at Groklaw, in Wiki format. The first allows interested parties to find and log in contradictions and objections, while the second tracks the ISO/IEC process. Pamela's own detailed writeup can be found here.

For further blog entries on ODF, click here

subscribe to the free Consortium Standards Bulletin
(and remember to Buy Your Books at Biff's)