143 lines
5.2 KiB
HTML
143 lines
5.2 KiB
HTML
<?xml version="1.0" encoding="UTF-8" ?>
|
|
|
|
<html>
|
|
<head>
|
|
<title>FSFE - The converter hoax</title>
|
|
</head>
|
|
|
|
<body>
|
|
<h1>The converter hoax</h1>
|
|
|
|
<p>
|
|
Originally published on Heise.de, 2007 July 16th.
|
|
</p>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<p>
|
|
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 <a href="msooxml-questions-for-ms.html">article</a> in the BBC
|
|
Technology news, influential groups like Gartner have swallowed the
|
|
converter claim hook, line and sinker.
|
|
</p>
|
|
|
|
<p>
|
|
Here is the problem: If these converters were actually able to do what
|
|
they promise to do, they would be unnecessary.
|
|
</p>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<p>
|
|
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?
|
|
</p>
|
|
|
|
<p>
|
|
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?
|
|
</p>
|
|
|
|
<p>
|
|
The answer to both questions is that it is not possible because two
|
|
things cannot be the same and different at the same time.
|
|
</p>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<p>
|
|
The promise of the converters is an empty one. It is a hoax.
|
|
</p>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<p>
|
|
But how can a user know which function is Microsoft specific?
|
|
</p>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<p>
|
|
More questions that you should be asking <a
|
|
href="msooxml-questions.html">are online</a>.
|
|
</p>
|
|
|
|
<h2>Related reading</h2>
|
|
|
|
<ul>
|
|
<li><a href="/documents/msooxml-interoperability.html">Interoperability woes with MS-OOXML</a></li>
|
|
<li><a href="/documents/msooxml-idiosyncrasies.html">DIS-29500: Deprecated before use?</a></li>
|
|
<li><a href="/documents/msooxml-questions.html">Six questions to national standardisation bodies</a></li>
|
|
<li><a href="/documents/msooxml-questions-for-ms.html">Questions for Microsoft on Open Formats</a></li>
|
|
</ul>
|
|
</body>
|
|
|
|
<timestamp>$Date$ $Author$</timestamp>
|
|
</html>
|
|
<!--
|
|
Local Variables: ***
|
|
mode: xml ***
|
|
End: ***
|
|
-->
|