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?
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.
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?
We’re trying to view it as a straight business decision. What are the costs associated with one approach over another? Does it serve all of our business needs? If it doesn’t serve a business need, how do we satisfy that business need? We’re trying to view this just as a plain-vanilla, nonpartisan, nonideological issue.
Group Bookmarks tagged
Gary Edwards (342)
marbux (24)
Jesper Lund Stocholm (9)
mazyar hedayat (4)
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~