The OOXML bunch is boringly disappointing.
19 01 2008And I’m not afraid to write it again: What are you guys think you’re doing? Level up the fight, I’m yawning!
First there is that “oh, we forgot we never gave you the specs of our binary file format” game popping up again through Brian Jones, as if nobody had seen that one coming. So what’s wrong with this? Let me write that again in an easy way: If Microsoft were truly delivering the whole specs, not only would the OOXML spec be at least half smaller, (why do you need all these mysteries about faithfully representing past application behaviors?), but the whole OOXML hoax would be made completely useless. Besides, there are two elements that are left undiscussed here: Wether Microsoft will actually deliver the specs entirely and not just partially just like they already did before, and when they will publish the specs. All what we have here is, yes, we will deliver you the specs, and you will be prompted to sign a license agreement before you can actually read anything, so that’s again an old story, just like they did during the ballot period in France.
By the way Brian, let’s go through the list of OOXML implementations you’re quoting in your blog: around 21 are being listed. The problem is, when you look carefully at that list, you discover there are only 3 genuine OOXML implementations, and yet most of them are only partial. There is yours, the one of MS Office, and we know you can’t even fully implement the Ecma spec but do implement your own, custom version of OOXML. Then there’s the one from Apple (iWork), although that’s just an import/export filter and it only works well for simple documents. I was surprized to unzip a .docx document the other day whose subfolders had been created in 1980. Yet another datation issue? Ahem. Let’s move on. Then there is the CleverAge/Novell plugin, and that one makes up for many of the other implementations you list, (Novell OpenOffice.org edition, Xandros, etc.) . The trouble is, this implementation is far to be effective, and you know it, but of course we will not argue about the dichotomy of the implementation and the specification. Then you have listed a set of implementations that I’d label under the “anything goes” category: they implement between 0 and 5 % of the OOXML spec, and they do it the easy way: you actually can label any document to be an OOXML file provided you make it start and end with the two proper namespaces. Not very interesting, I think.
Second, there is the Burton Group’s whitepaper on OOXML. (Disclosure: Ars Aperta, my company, is an independent firm providing strategic insights and management consultancy services on FOSS and Open Standards). The ODF Alliance wrote a very nice and granular rebuttal of their “study”. My point here is not that they wrote something in favor of the controversial OOXML format. The issue I have with the Burton’s study is that the arguments they are using are simply and flatly wrong. I guess one could ask the following question: “When is a consultant not a consultant?” If they really had to publish their take on the whole issue they should at least work on their topic, shoulnd’t they?
That’s not the case here, and even their stance on having written a study not commissioned by Microsoft or any other vendor falls short: Take a look here. Clearly speaking, the Burton Group is a Microsoft shop. That’s not an issue for me, but at least they could have tried harder.
I had come to expect more and better from the OOXML bunch. Perhaps they’re just hiding what they have in store for the BRM sessions, or afterwards in the 30 day period where national standards organization will have to make up their mind for a final decision on OOXML.
My fortune cookie of the day: “Never Ignore Evil”.
A couple of points,
“If Microsoft were truly delivering the whole specs, not only would the OOXML spec be at least half smaller, (why do you need all these mysteries about faithfully representing past application behaviors?),”
I’m not entirely sure what you mean. To me, if ECMA 376 included all what an implementor needs to support the file formats (create files, migrate, render, …), I think we are talking something in the range of 600,000 pages.
The fact that ECMA 376 is only 6000 pages proves immediately to me that Microsoft is just throwing a bone to us. They expect that this will be reviewed by people who for the most part have not really a lot of stake in it (i.e. they are no implementors).
“only 3 genuine OOXML implementations”
I don’t think that’s true. Gnumeric is genuine. On the other hand, the fact that Gnumeric has to map XML into its own memory data structure (designed to be compatible with the binary Excel, since Gnumeric is a ten year old project) is an example of failure of the XML-based file format itself. What I mean by that is that if the format was well designed, to maximize the virtues of XML (and therefore interoperability), then Gnumeric would simply load the file into a DOM, and apply all regular XML tooling (XSLT, Xpath, Xquery and so on). It’s not what Gnumeric does at all. It can be easily proven since the source code is available. That’s why OOXML is a failure, it does not advance the state of the art in office document models. That is to me a reason to reject it at ISO, until Microsoft comes up with something far better.
As for the Burton Group study, I have read the rebuttal by the ODF alliance and I have to say I am quite surprised between what the Burton Group arguments are, and what Microsoft own arguments are (particularly through the visibility of their bloggers : Doug Mahugh, and others). I mean by that, the arguments are exactly the same. It is very odd if this was a real study to come up with in fact not just the same arguments but even the same company names supposed to demonstrate how good OOXML is. The particularly ironic one is Mindjet, especially when you know that Doug Mahugh hired the Mindjet CTO last year to become a Microsoft evangelist (the post is here : http://blogs.msdn.com/dmahugh/archive/2007/06/22/san-francisco-workshop.aspx).
Stephane,
What I mean by OOXML being half smaller is this: if we had access to the full specs of the binary file formats, then the claim that OOXML has to represent past layouts and behaviours would be far less compelling and as such, OOXML itself would not integrate these “features”, partially or fully. Hence the OOXML spec, if it were to even exit in that wonderland, would be far smaller as it would only care about the present or perhaps the future.
In a more cunning way, one could point out that OOXML would then be useless compared to ODF…
Thank you for your input on Gnumeric!
“What I mean by OOXML being half smaller is this: if we had access to the full specs of the binary file formats, then the claim that OOXML has to represent past layouts and behaviours”
I understand what you mean now. But if Microsoft had to document every single detail of implementation of the binary format, the only way they would be able to do that would be to open up the source code. Indeed, the binary format specs that have been provided in the past are bare references (just like OOXML, bits are described with short sentences, and so on).
I think it’s fair to say that OOXML is not compelling as a standard since it’s just the binary formats with angle brackets. (to be honest they’ve added a few things, but nothing substantial : even their so-called “great” custom XML schemas were available in Word 2003 already).
I think that all the noise they made with their new user interface (Ribbon) was a PR scam to try to make IT people think that Office 2007 is really something new and worth upgrading it, even though that was just a change on the surface. That’s things like this that should be rebutted. But the Microsoft bulldozer is very powerful : no matter how right we are, they have the money to communicate much more effectively to their target customers (through PR wire).
As for OOXML versus ODF, I think it’s indeed the case that OOXML as we know it does not help the workplace and should be dismissed. We know that Microsoft chose not to work with the OASIS TC just because it was not their stuff, and being the paranoid freaks that they are, they try to protect themselves by reinventing the wheel every time.
This will come to an end though because in the enterprise space, a number of teams at Microsoft are duplicating features in a number of products, and there will be a crash at some point.
[…] is one rebuttal to Microsoft’s claim that its formats will be more open. First there is that “oh, we forgot we never gave you the specs of our binary file format” […]