Originally published on Heise.de, 2007 July 16th.
Conversion between Microsoft's Office OpenXML (MS-OOXML) and the vendor-independent Open Document Format (ODF) has been proposed by Microsoft and its associates as a solution to the problems caused by Microsoft's efforts to push a format into the market that conflicts with the existing Open Standard. Microsoft's business partners Novell, Xandros, Linspire and Turbolinux all committed themselves to work on the converter in the individual deals they signed.
Just like the UK National Archives fell for the myth of better archival through MS-OOXML, which has been analysed in more depth in a recent followup article in the BBC Technology news, influential groups like Gartner have swallowed the converter claim hook, line and sinker.
Here is the problem: If these converters were actually able to do what they promise to do, they would be unnecessary.
When the standardisation effort around Open Document Format (ODF) began, Microsoft was invited to participate, and chose to remain silent. Although people implore them until today to join the global standardisation effort, Microsoft does not contribute its ideas and suggestions to the multi-vendor Open Document Format.
Instead Microsoft focusses on MS-OOXML, which it promotes on the grounds of technical superiority and wider range of features. But if Microsoft's claims to technical superiority of MS-OOXML over ODF are true, how could one ever be converted perfectly into the other?
Microsoft maintains that while it would have been easy to support the Open Document Format (ODF) natively, it had to move to MS-OOXML because this was the only way for them to offer the full features of its office suite. But if Microsoft itself is not able to represent its internal data structures in the Open Document Format (ODF) in its Microsoft Office suite, how could an external conversion program from MS-OOXML accomplish this task?
The answer to both questions is that it is not possible because two things cannot be the same and different at the same time.
If the two formats could in fact represent the exact same data, there would be no reason for MS-OOXML to exist. And there would be no excuse for Microsoft not to use ODF natively for its office application.
So Microsoft had to add some additional features to make both formats represent different data and function sets. This means it will never be possible to convert all documents from one format to the other.
The promise of the converters is an empty one. It is a hoax.
If users of MS-OOXML make use of the Microsoft specific functions, they will find themselves locked into as much vendor and product-dependency as if no Open Standard or converter existed.
To gain at least some of the advantages of Open Standards, users of MS-OOXML would have to avoid using any of the Microsoft specific functions and features, and stay within the realm of the existing functionality of the converter.
But how can a user know which function is Microsoft specific?
Microsoft Office does not have warning labels on its buttons and it does not have a "use ODF-compliant functions only" setting. In fact, it does not even support the Open Document Format natively, because Microsoft has more interest in lock-in than competition.
The only effective way for users of Microsoft Office to avoid that lock-in into a single-vendor dependency would be to save all their documents in the Open Document Format (ODF) by using the ODF plugin for Microsoft.
In other words: The only way to not be locked into MS-OOXML is to stay away from it. Because no matter what Microsoft and its business partners claim, the converters promote lock-in, they don't avoid it.
More questions that you should be asking are online.