February 16th, 2007
Does ODF lack sufficient detail?
I missed this blog post by Mary Jo Foley on the debates surrounding ratification of OOXML by ISO. Unlike printed newspapers, however, which get thrown away shortly after the day for which they were printed has passed, online articles stick around forever. Heck, every article I've ever written for ZDNet can still be found on this site.
Anyway, I've read many articles elsewhere that chastised Microsoft for submitting so long an OOXML specification to ISO. The insinuation, of course, is that they've piled a bunch of unnecessary extras into the specification so as to confuse people and thus hinder interoperability. That post by Ms. Foley, however, pointed me towards some comments by Miguel de Icaza, father of the Mono project and Novell employee, where he made some interesting points on the subject (well, besides the ones Foley included in her blog).
A common objection to OOXML is that the specification is "too big", that 6,000 pages is a bit too much for a specification and that this would prevent third parties from implementing support for the standard.
Considering that for years we, the open source community, have been trying to extract as much information about protocols and file formats from Microsoft, this is actually a good thing.
For example, many years ago, when I was working on Gnumeric, one of the issues that we ran into was that the actual descriptions for functions and formulas in Excel was not entirely accurate from the public books you could buy.
OOXML devotes 324 pages of the standard to document the formulas and functions.
In other words, Microsoft goes into very precise detail in their specification in ways open source programmers have been wanting them to do for a very long time. In contrast, Mr. de Icaza had this to say about the much shorter section in the ODF specification that covers spreadsheet functions and formulas:
Depending on how you count, ODF has 4 to 10 pages devoted to it. There is no way you could build a spreadsheet software based on this specification.
To build a spreadsheet program based on ODF you would have to resort to an existing implementation source code (OpenOffice.org, Gnumeric) or you would have to resort to Microsoft's public documentation or ironically to the OOXML specification.
Miguel de Icaza himself highlighted that text in bold.
This is a point I've made before in other blog posts. A specification does not guarantee consistency in implementation. The more rigorous the specification, the more likely such consistency is to occur (though again, there is no guarantee…like I've said before, try releasing your "standards-compliant" web page without testing it in multiple browsers). As things stand, however, ODF doesn't appear to be rigorous enough to enable the much vaunted cross-platform and cross-implementation replaceability its advocates claim for it. This is sure to lead to individual implementations "filling in the gap," leading to a competition among implementations. If history is any guide, this often leads to the slow growth in market share of one implementation which in the end becomes the "de facto" standard, albeit one that includes standardized bits alongside the non-standard parts.
Of course, under such a scenario, that new leader might not be Microsoft. To many (IBM included), that is all that matters. Hence, preventing the standardization of OOXML is something to be encouraged.
It's one thing to say that a 6,000 page document format specification includes all the recipes from Grandma Jones extensive collection of cookbooks, a decades worth of advertisements from the pages of Time Magazine, and the complete text of Tolstoy's "War and Peace." It's another thing for the specification to be 6,000 pages and actually have real data essential to interoperability.
Most objections have been of the "omigod, this is too long" variety, not "omigod, there's nothing in here."
John Carroll has delivered his opinion on ZDNet since the last millennium. Since May 2008, he is no longer a Microsoft employee. He is currently working at a unified messaging-related startup. See his full profile and disclosure of his industry affiliations.
Subscribe to A Developer's View via Email alerts or RSS.
| 02/17/07
