Home > Standards Blog

Advanced Search 

Welcome to ConsortiumInfo.org
Sunday, April 20 2014 @ 02:24 PM CDT

Email Article To a Friend View Printable Version

The Contradictory Nature of OOXML

OpenDocument and OOXML

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)

The Contradictory Nature of OOXML | 38 comments | Create New Account
The following comments are owned by whomever posted them. This site is not responsible for what they say.
The Contradictory State of OOXML
Authored by: Anonymous on Wednesday, January 17 2007 @ 05:53 PM CST
A serious question: is there any practical point in finding and publicizing all of the bad things in OOXML?  (and there are some things, such as those you mentioned in this post, that any real standards organization would never have allowed)  What are you trying to accomplish?

Those that support OOXML do so for political reasons, not for technical reasons.  Those that support ODF do so mostly for political reasons, not technical reasons.  Thus, the technical merit of either spec is largely irrelevant,.

--- Swashbuckler


[ # ]
The Contradictory State of OOXML
Authored by: Anonymous on Wednesday, January 17 2007 @ 07:08 PM CST
Wrong. OOXML is supported for commercial, not political, reasons, and ODF is supported by anyone who wants interchangeable and lasting documents, as it is technically good and the only standard.


[ # ]
Beyond the Qestion of Patents
Authored by: darkonc on Wednesday, January 17 2007 @ 08:26 PM CST
Microsoft's description of these 'blobs' seems to imply that they expect the implementor to effectively reverse-engineer Word/97 and other 'legacy' versions of MS Works, MS Word and other MS Office products. It's been a while since I read the EULAs for those products, but I'm betting that some (if not all) of them claim to prohibit such reverse engineering.  In venues that claim to legitimize shrink-wrap licenses, this means that -- even if Microsoft were to grant the necessary patent rights needed to implement those blobs, an implementor might find themself embroiled in a legal fight with Microsoft as to whether or not the information necessary to complete the information was gained legally.

In other words, if Microsoft doesn't fill in the blanks for these proprietary and/or legacy blobs, an implementor might find, in addition to the technical problems, not one -- but two -- legal hurdles should they ever succeed at implementing OOXML.        
[ # ]
The Contradictory Nature of OOXML
Authored by: Anonymous on Thursday, January 18 2007 @ 04:03 AM CST
OOXML seems a bit like EBCDIC (a single-vendor standard really intended for use with punch-cards), playing opposite ISO ODF XML being like ASCII (American Standard Code for ..., a vendor-neutral standard really intended for use with paper tape).

It's good that Microsoft have finally coughed up a description, it may well take 50 years to work its way out of the 'system', just as ASCII-based representations are slowly pushing EBCDIC-based representations out. Punch cards and paper tape are both long gone, but we still need some way of agreeing what the zeros and ones in our computers mean.

But there should be no need for ISO to bless a single-vendor standard.

[ # ]
The Contradictory Nature of OOXML
Authored by: Anonymous on Thursday, January 18 2007 @ 10:09 AM CST
&lt;p&gt;Andy,&lt;p&gt;<br>Just how does one find out who is the 'national standards body' is for any given country and equally important, how to contact them?&lt;p&gt;<br>Presumably for the US, the National Bureau of Standards {?} is the correct body. But then who to contact? Actually, I think they're now the National Institute of Standards and Technology. {www.nist.gov}&lt;p&gt;<br><br>
[ # ]
It's a contradiction, all right!
Authored by: Anonymous on Thursday, January 18 2007 @ 10:34 AM CST
OpenDocumentFellowship has a document that defines what a standards "contradiction" is. That's important, because specifications aren't supposed to enter the fast track if there's a serious contradiction.

And this case, there are lots of massive, fatal contradictions that should immediately derail the "fast track" (and really, the whole specification). Let's look at the possible reasons for a contradiction:

  1. confusion of users: Users may be confused by the "term 'open'"; users might think it means that the specification represents some sort of industry consensus, or a specification that is widely implemented by many suppliers, or one with fully open IPR (e.g., so partial implementations and later versions are unencumbered). This is not true. For example, there doesn't seem to be a legal way for others to fully implement it (due copyright on material like graphics borders and EULAs forbidding reverse engineering for inadequately specified pieces). This specification does not meet many of the common definitions of the term "open standard". Users may also confuse the specification with OpenOffice.org, a product that implements OpenDocument instead.
  2. damage to ISO reputation: If it accepts this specification, ISO will be tarred as an organization that can be controlled by any single powerful company, instead of one that strives for broad industry consensus and protection of users' interests. Look at the precedent this sets - if ISO accepts this specification, it means that a rich company can overturn any existing standard (e.g., OpenDocument) simply by buying off a standards organization (ECMA) to accept whatever they write. ISO's key value is in its reputation for impartiality, and should not sully such a valuable reputation for such an obvious ploy.
  3. lack of consistency with existing standards: Obviously this isn't consistent with ISO/IEC 26300 (OpenDocument). Which was approved as an ISO standard in 2006, so it's clearly not obsolete. What's worse, it's completely inconsistent with other standards: MathML, SVG, XForms, and so on.
  4. duplication of existing standards: It duplicates OpenDocument. Completely. There's no "different market" for office documentation; it's all the same market. Indeed, the fact that people are working on bidirectional translators shows that they are the same thing. There's no need for yet another standard for the same thing, unless of course you're trying to ensure that a single vendor controls the format of all office documents.
  5. overlap with existing standards: I wish it were just "overlap". This is essentially a complete duplication of an existing standard, for the sole purpose of enriching a single company (at the expense of competition in the marketplace).

Another problem is that the specification, for all its pages, doesn't get to the meat of the specification. You can't really implement it without "secret sauce" information that only Microsoft has. It's a non-specification specification. It's only so long because they had to re-create incompatible specifications for functions that are open standards elsewhere (like MathML and SVG).

This specification is also grossly immature; even if were not a contradiction, it's not ready. It can't be otherwise:

  1. It was developed in a rush - 6000 pages in less than a year (!). In contrast, OpenDocument development began December 16, 2002 and was approved May 1, 2005. And OpenDocument development was much easier, because they reused standards (like SVG and MathML) wherever they could, instead of recreating things from scratch.
  2. Nearly all office application developers were not involved in the ECMA process (for development OR review), for good reasons. After all, nearly all office application suppliers had spent years working to develop a standard; there was no need to do it again (note that the ECMA process only started many months after OpenDocument had been completed). The ECMA process, by charter, was clearly unfair and tilted towards the whim of a single vendor. And technically, because the specification completely redoes from scratch many standards areas (like MathML and SVG), there are many good reasons to avoid implementing this specification.

There's no terrible harm to Microsoft if ISO rejects fast track status, or even the spec outright. Microsoft can implement the industry-developed international ISO standard (OpenDocument) any time it wants to. If there are problems with the standard, they can be addressed through normal standards processes. But allowing a single company to create its own incompatible, essentially proprietary standard will do great harm to the reputation of all standards bodies.

ISO says its goal is "one standard, one test, and one conformity assessment procedure accepted everywhere. Do they mean it? Or is that a lie, just another empty claim that can be sold to the highest bidder? Is it possible for an industry to work together for many years to develop and implement a standard, and then as the standard begins to be adopted, for a single vendor to write its own incompatible specification and get ISO's endorsement?

We'll see if ISO can really stand for its principles. I hope, and have reason to believe, that ISO can, and reject the fast track request.

(I previously posted this on Groklaw.)


[ # ]
  • No terrible harm? - Authored by: Anonymous on Friday, January 19 2007 @ 11:15 PM CST
The Contradictory Nature of OOXML
Authored by: Bill Poser on Friday, January 19 2007 @ 01:59 AM CST

The language codes on pp. 2531-2537 of the Open XML spec are said to consist of exactly two hexadecimal digits, yet they range from 1033 to 58380. These are not hexadecimal values and cannot be represented by two hex digits. Am I missing something, or has Microsoft screwed this up?

[ # ]
Andy, can you explain ...
Authored by: Anonymous on Saturday, January 20 2007 @ 08:47 AM CST
Under the fast track process it appears that there is a 1 month (calendar month?) review period, followed by a 5 month voting period.

What does this mean in practice?
Do the NSBs vote once only? Or can they vote with objections and then alter the vote if they wish?

Do they vote at any time during the process or just at end beginning/end?
Are the NSBs very political or is it worth trying to influence them by making direct contact?
What sort of arguments are likely to be effective?

Thanks,
felix_the_mac, Groklaw


[ # ]
www.anyofficesuite.org
Authored by: Anonymous on Monday, January 22 2007 @ 03:13 PM CST
Time to take a stand and support ODF in actions. See www.anyofficesuite.org .
[ # ]
The Contradictory Nature of OOXML
Authored by: Anonymous on Thursday, January 25 2007 @ 02:11 PM CST

What is silly is that you are suggesting one would use a representational date format for use in spreadsheet. You better tell me that Opendocument uses an alternative date format for spreadsheet  or I'll cry.

Also it is pretty clear that the ODF spec allows for ambedding of any arbitrary  filetype whatasoever via xlinks for instance. That mean that you could in theory create an ODF document that consist entirly of an OOXML embeddend document.

The fact that OOXML has the possibility to do OLE embedded linking seems pretty simular.

Simular to ODF you could ignore any embedded objects if there is no support for the format present.

The only thing you can say is that OLE embedded links will be not be very crossplatform but it does not require any embedded format to be part of the format just as ODF does not have any possible embedded format in it's spec.

[ # ]