Short slide deck of Barbara Held's February 28th, 2007 EU IDABC presentation. She introduces ODEF, the "Open Document Exchange Format" which is designed to replace
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~

Tim Anderson interviews Microsoft's Jean Paoli about MOOXML and ODF.    Jean Paoli of course has the predictable set of answers.  But Tim anderson provides us with some interesting insights and comments of his own.  There is also a gem of a comment from Stephane Rodriquez, the reknown spreadsheet expert.

The bottom line for Microsoft has not changed.  MOOXML exists because of the need for an XML file format compatible with the legacy of existing MSOffic ebinary documents.  He claims that ODF is not compatible, and offers the "page borders" issue as an example.

Page borders?  What's that got to do with the ODF file format?   These are application specific, application bound proprietary graphics that can not be ported to any other application - like OpenOffice.  The reason has nothign whatsoever to do with ODF and everything to do with the fact that the page border library is bound to MSOffice and not available to other applications like OpenOffice. 

So here is an application specific feature tha tJean Paoli claims can not be expressed in ODF, but can in MOOXML.  But when are running the da Vinci ODF plugin in MSWord, there is no problem whatsoever in capturing the page borders in ODF!!!!!!!!!!!!!!!!!!!!!!!!!!!  No problem!!!!!!!!!!

The problem is opening up that same da Vinci MSWord document in OpenOffice.  That's where the page borders are dropped.  The issue is based entirely on the fact that OpenOffice is unable to render these MSWord specific graphics bound to an MSOffice only library.

If however we take that same page border loaded da Vinci MSWord document, and send it half way across the world to another MSWord desktop running da Vinci, the da Vinci plugin easily loads the ODF document into MSWord where it is perfectly rendered, page borders and all!!!!!!!!

Now i will admit that this is one very difficult issue to understand.  If not for da Vinci, we would have to take Microsoft's word that they can't capture those sacred page borders in ODF so therefore they must invent their own XML:  MOOXML.

But hey, this is Microsoft.  Who in their right mind would take them at their word? 

The problem is that one first has to invent an "internal" ODF plugin for MSOffice to prove that Microsoft has it wrong (okay, i'm being kind here :)  And inventing such an internal plugin is one daunting and difficult task.  See, the only way an ODF plugin can work "internally" would be to be able to convert perfectly between MSOffice in-memory-binary-representations  and ODF.

This involves the perfect fidelity conversion of those infamous billions fo binary documents to ODF.

Since Microsoft fully understands and owns the complete blueprint for those billions of binary documents, they can perfect the conversion to MOOXML.  But without this secret knowledge, it's near impossible for anyone to match this feat;  as in converting those same documents to ODF XML.

This isn't the time or place to explain how da Vinci does it, but it does.  The larger point here is that Microsoft intentionally confuses ODF the XML file format with OpenOffice the office suit application.  They take a binary MSWOrd document with page borders, and import it into OpenOffice using the OOo reverse engineering conversion filters.  Then they save the document as "ODF".  And of course it's a mess.  The page borders are no where to be found.

Is this an OpenOffice problem?  Or a problem for ODF?

Without da Vinci one would have to say it's probably a little of both.  The truth however is that this is entirely a OpenOffice problem.  The truth is that ODF can handle ANYTHING MSOffice has to throw at it.

We know this because we see what da Vinci can do. 

To most people it makes sense that applications with different features would of course need different file formats able to capture those features. Especially advanced features.

But that's only true if the fiel format in question lacks the needed flexibiltiy.  Maybe MOOXML does lack that kind of extendable flexibility.  But it's not true of ODF!!!!! 

An incredibly extensible and flexible model was built into ODF exactly for the purposes of being able to handle anything MSOffice documents could throw at ODF.  And while it's true that by nature, XML is rigid, hard coded, with a strictly structured and inflexible hierachy, ODF was designed for near infinite flexiblity.  It's all there, but it's not something Mcirsoft wants anyone to know about or understand.

~ge~

Great interview. Tim can obviously run circles around poor Jean Paoli.

A mus tread.  Carol Sliwa of ComputerWorld intervies Clark Kelso, California CIO.  ODF is the main issue, with clark casting all his answers in the context of business decisions.  Carol o fcourse is asking the best questions of any journalist alive.

Keep in mind that ComputerWorld and the Boston globe filed for the Freedom of Information Act to be invoked in Massachusetts.  They got access to all the eMail, documnetation, and conferencing notes concerning ODF  and Microsoft.  Carol's interview with Louis Gutierrez last week was filled with the same hard questions Clark Kelso fielded so deftly.

The "committee" Clark Kelso has set up to look at these issues is headed by Bill Welty, the CIO of the California Air Resources Board.  Bill is a long time opensource - Linux guy, but will be the firs tto admit that Microsoft is the only vendor providing a means of getting everything inot XML.  And that's the heart of any SOA strategy, "First, get everything into XML".

With a 500 million MSOffice desktop bound business process headstart, Microsoft has the extreme advantage in this much needed migration to XML. 

They now have their own proprietary application and platform bound version of XML; MOOXML (Microsoft OfficeOpenXML) heading for international standardization at ISO. 

They now have their XML Hub in place; the Exchange4/SharePoint Hub.  This is also an essential part of any SOA strategy.  You've got to have an XML Hub where the XML information streams and service connection to legacy black box systems can be piped into, managed and resolved.  The XML must also provide an end user interface to these information flows.  One that converges and integrates information, documents, data, and workflows into an easy to manage and participate in interface.  The E/S Hub excells at this because it covers the fundamentals of eMail, messaging, portal, calendar, scheduling, contact and project management, document resources, CMS, workgroup and workflow management, XML forms, data schemas, data binding and extraction.  The "portal" element provides vertical market developers with an easy means for provisioning highly productive business processes designed to replace those bound to MSOffice desktops.

Micrsoft is ready to play XML and SOA.  And do so without giving up their control of the documents or API.  The cornerstone of the MS XML STack is that every applicaiton on the desktop, server, device or Web shares three common factors:

• MOOXML (Microsoft OfficeOpenXML)
• .NET 3.0 Components, Libraries and Data Schemas
• XAML - the XML presentation layer (GUI)

So, where are the ODF Hubs?  And will those Hubs have the same level o integration to the MSOffice desktop as the MS XML Hub enjoys? 

~ge~