
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:
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: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.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
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)
- 50603 views
Comments
The Contradictory State of OOXML
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
First, I take issue with your oversimplification that it's all politics and no technology. Obviously there is political motivation involved on both sides, but there are more important things to be considered.
ODF is a format which was developed to be a truly open standard that anyone could implement. When Massachusetts decided to go with ODF, the logic was simple; they wanted someone 100 years from now to be able to create a program (or whatever it'll be called then) from scratch that can open and display a document that had been archived. This is not a trivial issue.
Massive amounts of information (including census data, I believe) is literally rotting into oblivion. The old magnetic tapes are deteriorating, and no computer of any kind exists that can read those tapes, much less do anything with what's on there. Governments, particularly, deal in decades and centuries, not quarters and years. ODF is an attempt to avoid the mistakes of the past going forward.
OOXML, by all accounts I have read (which is a lot), is an attempt by Microsoft to legitimize its own proprietary format as an alternative standard. I cannot see ANY way that this mess could be the basis of a long-term open standard by which someone 100 years from now could create a program from scratch to open OOXML documents. The information presented here (and in other places) demonstrates that the specification as submitted could not be used to create a working program from scratch on any platform (even Microsoft Windows!), today or 100 years from now. It is widely regarded (and I believe correctly) that the sole purpose of trying to get OOXML established as an ISO standard is for short-term (as in the next few years) marketing purposes by Microsoft.
I will further submit that if your argument has no more depth than what you have said, then you, sir or madam, are a troll. Hie thee back under thy bridge!!!!!!!
Weeble
The Contradictory State of OOXML
I think the problem I have, and likely Microsoft as well, is that there are literally Millions of existing documents with varying kinds of formatting that need to be converted to any long term storage format for the idea to even hold any water. It doesn't really help if only new documents can be accurately represented by the format. There are varying degrees of accuracy in conversion from legacy office format files to ODF, but in my experience, all but the most basic kinds of documents fail spectacularly in the process and need some kind of touch-up. It gets even worse when you need to represent the document as it was originally created for legal or artistic reasons.
What I think Microsoft needs to do is restructure OOXML to provide for legacy formatting, but leaving a core sane format. Some might argue that this format should be ODF, but I can already see everyone and their dog accusing Microsoft of "embrace, extend, extinguish" tactics if they did so. They could even be sued on anti-trust grounds for doing so.
The fact that there are already millions of documents that need to be represented by an open format alone is enough to justify an ISO standard for such documents.
The Contradictory State of OOXML
The Contradictory State of OOXML
Exactly.
All the crap about bugs in previous versions of the applications should have been corrected as a part of the import process, not propagated for all time.
--- Swashbuckler
The Contradictory State of OOXML
The Contradictory State of OOXML
However, I cannot see that occurring under the present management of Microsoft.
The Contradictory State of OOXML
They made it bad and want you to pay for it every year.
If you have document in latex, pdf, ... You can see it and work on it today, like 10, 20 years before. If you have something in M$ oficcee version 3.1415 you are in trouble.
When I was in university, I remember one mathematician, who said ouch, I have to have Word 2.0, 3.0, 4.0, 5.0, and some more minor releases, if I want to read papers from my colleagues.
In 100 years you have to have aproximately 60-70 releases of various M$ office packages, if you want to read documents. If you write doc in latex, pdf, odf(hopefully|, you'll still need one software for reading it, as you do 100 years before.
The Contradictory State of OOXML
It's like the invasion of Iraq, the Bush administration claimed there were WMD, they wanted to free the Iraqi people, spread democracy, etc. But the real reason they went in is because they wanted to get rid of Saddam.
Same kind of thing here. Just because something has a benefit, doesn't mean it's a reason something was done.
--- Swashbuckler
OK, So I'm Probably Feeding a Troll...
And there are good reasons for taking that stance. From its earliest days, Microsoft (then Micro-soft) has built and maintained its business by cheating, stealing other people's ideas (has Microsoft REALLY been innovative other than in creating "Microsoft Bob"?), using its market power in an extremely predatory manner (established as fact in U.S. v. Microsoft), undermining competitors with false claims of products that showed up far late if at all (i.e., vaporware) as well as with subtle half-truths and lies commonly known as FUD, protecting the slop it calls software via vendor lock-in, and the list goes on and on.
Some do promote ODF/open source/FOSS/Linux/etc. partly or primarily because they detest Microsoft. However, from what I've seen (and I've seen a lot), most do so out of altruism, desiring to better their world, and from a desire to "build a better mousetrap". This is specifically so with ODF.
Please, sir, if Microsoft's desire to promote their proprietary OOXML format by seeking ISO certification based on a half-baked document that enables no one but themselves to implement it (because only they can fill in the blanks) is based on altruism, desiring to better their world and/or a desire to build a better mousetrap, where is the evidence of this?
All I have seen in your posts so far are half-truths, innuendo and ad hominem arguments. I challenge you to provide some fact-based arguments that ODF is being promoted primarily because of a vendetta against Microsoft (as opposed to the altruistic motives mentioned above) or else admit you are a troll AND GET YOURSELF BACK UNDER YOUR BRIDGE!
OK, So I'm Probably Feeding a Troll...
The Contradictory State of OOXML
Whether your reasons for supporting ODF or OOXML are technical or political, there are a number of technical (and possibly also political) reasons for looking for the flaws in this proposed standard:
You're going to get a far better listening if you say "It has these M minor problems, these N serious problems, and these K probably insurmountable and structural problems, and I think that these flaws are so serious that OOXML should be completely rejected."
As many people have pointed out -- despite being a massive 6000 page document, the OOXML proposed standard doesn't actually have enough information for anybody (other than Microsoft) to implement it -- and what's value of a 'standard' that only one entity can implement?
The Contradictory State of OOXML
I'm replying late to your questions (my apologies), and I think that those who have already replied have covered the ground pretty nicely. Here are a few more thoughts around the edges.
First, the fact that ODF can (and actually has) been implemented in many products means that its a lot more likely that documents will stay available over time - in part because more developers will have motivations to support it than OOXML. And many other good things will follow as well, such as choice, price and feature competition, and so on. None of that will happen with OOXML, which is more like a more open (but not completely open) toolkit for a single product than a standard.
On another point, there's no question that the genesis, and much of the current support, for ODF was and is "political" in the commerical sense (if that's what you meant) in that the core came from Sun, and the standard is being pushed as hard as possible by vendors (most notably IBM and Sun) for commercial advantage. But it's also true that ODF has a large and growing following of open source developers and customers, which are not motivated by politics, or at least by the same type of politics.
In that sense, you could anlogize loosely to Linux, which points back to UNIX - a commercial product. Linux is, of course, beloved by open source developers and customers alike, while at the same time being pushed hard by commercial vendors for the traditional profit and competitive reasons.
- Andy
The Contradictory State of OOXML
Some will support Microsoft in (nearly) anything they do because Microsoft did it and their fortunes depend upon Microsoft. Some will oppose Microsoft in literally anything they do because they dislike Microsoft for any variety of reasons.
Do you believe that any company or open source project is going to chose to support or not support OOXML based on the technical merits of OOXML? I don't. If Microsoft hadn't put all the stupid requirements to replicate bugs from previous versions of Office into OOXML would that have affected the decision of any company or project? I don't think so. Thus, while the stupid stuff in OOXML is interesting, pointing it out seems to serve no practical purpose; it merely allows those that oppose OOXML to say "See, I told you!"
You can't even use this to really slam ECMA, as it has long been known as a rubberstamp "standards" organization. I had some involvement in a couple of ECMA efforts ten years ago, and that was the case then and it's still the case today.
--- Swashbuckler
The Contradictory State of OOXML
OOXML is NOT a document format for going forward. Rather, it is a document format intended to reach back to the past and carry it along. That's a recipe for disaster, not for a standard. Such a format could only become more and more bloated as it has to support more and more emulated characteristics.
Maybe I'm dumb, but an office package that costs as much as Microsoft Office does should, when importing a document, be able to translate the document into its own terms rather than simply emulate characteristics of the old format. And when the document is saved in the new format, all of the characteristics should be in terms of the new format. It has been a surprise to me to learn that the older MS Office formats didn't do that. If they can't or won't do the work to translate a document's characteristics into those of the new format, the default should have been to save it back in its existing format.
Even if I *wasn't* of such a strong negative opinion about Microsoft, I'd still think this is a stupid way to run a railroad. Or a software company.
The Contradictory State of OOXML
I, for one, do not have the time to read the standard, and do the research that will show me how much in deep trouble I could be if I moved my documents to OOXML. Note that it does not matter if I would actually consider doing it or not: it is obvious that this is a political fight, but even political fights can be won by public pressure (and, alas, note again that public pressure can win the "right" fight, or the wrong one).
ISO is, as any other organisation, a political beast, and will sometimes react to political rather than technical merits.
The Contradictory State of OOXML
The Contradictory State of OOXML
right.
from Michael @ <a href=http://www.tinpok.com/>tinpok.com</a>: <a href=http://www.tinpok.com/>Hong Kong Web Category</a>
Beyond the Qestion of Patents
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
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
The Contradictory Nature of OOXML
Vance
The Contradictory Nature of OOXML
Harish
h dot pillay at ieee dot org
In the UK it is the BSI
It's a contradiction, all right!
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:
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:
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?
It's a contradiction, all right!
thinking your point. I think you are right.
from Michael @ tinpok.com
The Contradictory Nature of OOXML
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?
The Contradictory Nature of OOXML
The Contradictory Nature of OOXML
Andy, can you explain ...
Andy, can you explain ...
www.anyofficesuite.org
The Contradictory Nature of OOXML
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.
The Contradictory Nature of OOXML and OpenDocument
ODF specification
paragraph 9.3.5 Plugins
A plugin is a binary object that is plugged into a document to represent a media-type that usually is not handled natively by office application software.
Is that not the same that happens with OLE embedded objects.
Mayby you should retitle the article the contradictory nature of both OOXML AND OpenDocument ?????
OpenDocument requires JavaVM
In ODF Java applets are defined as a native part of ODF documents.
I guess that is Sun's way to require that any full implemention of the ODF spec needs a Java Virtual Machine to be present ????