And 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”.