OOXML vs ODF: where next for interoperability?
'A diversion from the real end game – the taking of the internet'
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
Gary Edwards of the Open Document Foundation has a fascinating post on the important of Microsoft Office compatibility to the success of the ISO-approved Open Document formats.
It is in places a rare voice of sanity:
People continue to insist that if only Microsoft would implement ODF natively in MSOffice, we could all hop on down the yellow brick road, hand in hand, singing kumbaya to beat the band. Sadly, life doesn’t work that way. Wish it did.
Sure, Microsoft could implement ODF - but only with the addition of application specific extensions to the current ODF specification … Sun has already made it clear at the OASIS ODF TC that they are not going to compromise (or degrade) the new and innovative features and implementation model of OpenOffice just to be compatible with the existing 550 million MSOffice desktops.
More:
The simple truth is that ODF was not designed to be compatible – interoperable with existing Microsoft documents, applications and processes. Nor was it designed for grand convergence. And as we found out in our five years participation at the OASIS ODF TC, there is an across the boards resistance to extending ODF to be compatible with Microsoft documents, applications and processes.
Summary: in Edwards’ opinion, there are technical and political reasons why seamless ODF interop cannot be baked into Microsoft Office. Therefore the Foundation is now working on interop with the W3C’s Compound Document Format, about which I know little.
Surprisingly, Edwards also says that ODF will fail in the market:
If we can't convert existing MS documents, applications and processes to ODF, then the market has no other choice but to transition to MS-OOXML.
Edwards is thoroughly spooked by the success of Sharepoint in conjunction with Exchange, and overstates his case:
If we can't neutralize and re purpose MSOffice, the future will belong to MS-OOXML and the MS Stack. Note the MS Stack noticeably replaces W3C Open Web technologies with Microsoft's own embraced “enhancements”. Starting with MS-OOXML/Smart Tags as a replacement for HTML-XHTML-RDF Metadata. HTML and the Open Web are the targets here. ODF is being used as a diversion from the real end game – the taking of the Internet.
I find this implausible. At the same time, I agree about the importance of interoperability with Microsoft Office.
I would also like clarification on what are the limitations of OOXML / ODF conversion. Here's a technique that does a reasonable job. Open OOXML in Microsoft Office, save to binary Office format. Open binary Office format in Open Office, save as ODF. The same works in reverse. Not perfect perhaps, but a whole lot better than the Microsoft-sponsored add-in that works through XSLT. Could this existing Open Office code be made into a Microsoft Office plug-in, and if so, what proportion of existing documents would not be satisfactorily converted?
Note that Sun's ODF converter seems to be exactly this, except that it does not yet work with Office 2007. It could presumably be used with Office 2003 and the OOXML add-in, to provide a way to convert OOXML to ODF in a single application. Some further notes on Sun’s converter here.
A freelance writer since 1992, Tim Anderson specialises in programming and Internet development topics. He is a contributor to lots of publications, including Register Developer. You can find his blog here.
COMMENTS
Not so flawed
Gary describes very well how Microsoft leverages its monopoly: don't focus on a single product like Office for example, but how the Microsoft's products interact altogether. The point is not just about a file format but its combination with the rest.
For him, the goal is to slow this fiendly strategy which leads quickly the users to the point of no return; so, don't fight in the Office battleground and take an edge in the collaborative battleground.
Besides that, we can consider ourself in a jail: an escape is risky and costly if we get caugth. Hence, we invest in freedom or nothing, but that involves a collective move.
Gary's analysis is flawed
So please don't repeat it without discussion. There are no significant features of MS Office that cannot be mapped to ODF, if not to v1.0 then v1.2.
More importantly, it is absolutely and entirely the wrong approach in developing a standard to start by ensuring you can reproduce all the flaws of legacy pre-standardisation approaches. For certain you should examine existing approaches and learn from them, but not mimic them to satisfy a particular organisation, no matter how dominant.
Note: Microsoft personnel have already stated they could support ODF in discussions around Massachusetts - maybe that would be in a way that would inhibit those documents being used in Sharepoint. I care not if Sharepoint or other Microsoft technologies are so limited. What I demand is that we have a common, documented and unencumbered file format that allows for seamless interchange of documents.
Notes for those who see 550 million installed seats of a product as proof positive that is all we should care about:
(i) they ain't all the same product i.e. are not all compatible with each other in the seamless idealism Gary espouses;
(ii) within 5 years, 550 million will be less than a tenth of the devices in active use capable of read/writing an office-type document.
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Enabling efficient data center monitoring
