What’s distinctive about the goals of OOXML? Primarily, to have full fidelity with pre-existing binary documents created in Microsoft Office. “What people want is to make sure that their billions of important documents can be saved in a format where they don’t lose any information. As a design goal, we said that those formats have to represent all the information that enables high-fidelity migration from the binary formats”, says Paoli. He mentions work with institutions including the British Library and the US Library of Congress, concerned to preserve the information in their electronic archive.
I asked Paoli if such users could get equally good fidelity by converting their documents to ODF. “Absolutely not,” he says. “I am very clear on that. Those two formats are done for different reasons.”
What can go wrong? Paoli gives as an example the myriad ways borders can be drawn round tables in Microsoft Office and all its legacy versions. “There are 100 ways to draw the lines around a table,” he says. “The Open XML format has them all, but ODF which has not been designed for backward compatibility, does not have them. It’s really the tip of the iceberg. So if someone translates a binary document with a table to ODF, you will lose the framing details. That is just a very small example.”






both ODF and OpenOfficeXML.
ComputerWorld recently ran a story about the end of ODF, as they covered the failure of six "legislative" initiatives designed to mandate ODF as the official file format. While the political treachery surrounding these initiatives is a story in and of itself, the larger story, the one that has world wide reverberations, wasn't mentioned.
The larger ODF story is that ODF vendors are losing the political battles because they are unable to provide government CIO's with real world solutions. Here are three quotes from the California discussion that really say it all:
“Interoperability isn't just a feature. It's the basic requirement for getting your XML file format and applications considered”.....
“The challenge is that of migrating our existing documents and business processes to XML. The question is which XML? OpenDocument or OpenXML?” .......
“Under those conditions, is it even possible to implement OpenDocument?” ....... Bill Welty, CIO California Air Resource Board wondering if there was a way to support California legislative proposal AB-1668.
This is hardly the first time the compatibility-interoperability issue has challenged ODf. Massachusetts spent a full year on a pilot study testing the top tier of ODF solutions: OpenOffice, StarOffice, Novell Office and IBM's WorkPlace (prototype). The results were a disaster for ODF. So much so that the 300 page pilot study report and accompanying comments wiki have never seen the light of day.
In response to the disastrous pilot study, Massachusetts issued their now infamous RFi; a "request for information" about whether it's possible or not to write an ODF plugin for MSOffice applications.
The OpenDocument Foundation responded to the RFi with our da Vinci plugin. The quick description of da Vinci is that it's a clone of Microsoft's own OfficeOpenXML plugin for MSOffice - also know as the Microsoft XML Compatibility Kit.
When we got into the Massachusetts trials, and had a chance to see the problem up close and personal, we changed completely our viewpoint on compatibility, interoperability, and convergence. The pilot study was right. There is no way to implement ODF into any situation where MSOffice wokgroup - workflow bound business processes are prominent.
What we learned in Massachusetts is that there are two barriers to entry for ODF. The first is the file format barrier - the ability to convert existing binary documents to ODF. The second is the MSOffice workgroups where bound business processes, integrated line of business apps, and comprehensive add-ons like those involving assitive technologies form an impossible barrier. Impossible except for an "internal" XML file format plugin; an ODF plugin like da Vinci or the MS XML Compatibility plugin.
The MSOffice "workgroup - workflow" business process barrier is the ODF show stopper. It's why ODF alternatives like OpenOffice, StarOffice, WorkPlace and Novell Office can't be used. It's also why the LiNUX Desktop has zero traction in the business world!
And it's also why every effort "had" to be made to accommodate the "compatibility-interoperability-convergence" needs of internal ODF plugin converters and translators. As represented by the Foundation's da Vinci and Novell's OfficeOpenXML Translator plugin for OpenOffice. If ODF can't crack the workgroup-workflow barrier, it's over.
So what's the problem? Why is it that ODF has failed at the CIO - "how the hell do we implement ODF" level? Why is it that governments the world over are turning to this new file format, ODEF? A file format that not only lacks application support, but also lacks a written specification and governance body?
Read through the IDABC ODEF web site, and you'll find some truly interesting observations; IDABC ODEF Workshop 2007 in Berlin
They reject both ODF and OfficeOpenXML. They even reject ISO! Which is to say they don't trust the big vendor standards consortia either (OASIS and ECMA) - with good reason i might add. They also hit hard the big vendor "interop break points" that are set by "optional" implementation requiements, supersets, and sub sets.
While i have no idea about the politics behind ODEF, i agree 100% with what they are trying to do. Compatibiltiy, interoperability and convergence are extremely important file format concerns. Concerns that should not be traded off as deal making inducements by big vendors. In fact, "interoperability" has long been a central component of Microsoft deal making. Going back to Netscape, Java, the MS-Sun 2004 deal, and now the MS-Novell-IBM deals.
So it's not surprising that the EU IDABC is taking such a strong anti big vendor position. The problem they have to overcome is that the big vendors control both the applications and the standards processes!
It's easy for the EU to write ODEF. We of course would like to contribute our 2 cents concerning compatibiltiy, interoperability and convergence. Our changes to the ODF specification can be summarized in less than one page. We would still need to clean out all the OpenOffice specific aspects of ODF, but we know exactly where those interop bombs are.
Most importantly though, if we get a workable ODEF specification from the EU, we will write an ODEF da Vinci plugin for both MSOffice and OpenOffice.
Just when we thought it was over for ODF, the EU rides to the rescue. Again.
~ge~