Microsoft continues to give its bizarre argument that multiple competing (conflicting) standards for the same purpose is a good thing. They are dreadfully confused. Having multiple competing products is a good thing, but having multiple competing standards is terrible.
Multiple competing standards risk massive property loss, many lives, and even the loss of your country, according to history. My presentation Open Standards and Security notes two of the many historical examples, the 1904 Baltimore fire and the U.S. Civil war:
But what about document converters, don’t they make it easy to have multiple competing standards? Well, it’s true that there are converters like ODF Converter. But while converters are very useful for one-time transitions, they are lousy long-term solutions… they make it clear that there has been a failure, not a success, in standards-making. Look at the problems multiple standards cause in other areas. We can easily convert between metric and English units, but NASA lost a $125 million Mars orbiter because a Lockheed Martin engineering team used English units of measurement while the agency’s team used the more conventional metric system. Another example is the Gimli Glider, a Boeing 767 that ran out of fuel in Canada in 1983 due, in large part, to confusion about English/metric conversion. Why do we want this problem in office documents too? Also, as of June 5, 2007, there are 6 pages of problems converting MS XML to ODF, but only 2 pages of problems converting ODF to MS XML. In general, ODF appears to be a much more capable format; just from that list it appears that it’ll be easier to improve ODF than to try to use MS XML for all documents. Which is unsurprising; the ODF work included membership from a variety of office suite implementors, while MS XML is the work of just one. That’s even more true when you consider that OpenDocument uses existing standards, instead of creating a trade barrier through nonsense one-off specifications. Microsoft claims that OOXML is necessary to “fully” capture old binary documents, but I have not seen much evidence this is actually true. A quick look at the CONVERT function in OOXML revealed many absolutely incorrect unit measures, for example. More generally, I have no reason to believe that the OOXML spec actually includes what is needed to capture the older binary formats like .doc - no mapping has been presented to prove this claim, and it’d be easy for the OOXML spec to omit lots of important information.
Regardless of the facts, Microsoft continues to press for ISO standardization of its format, aka “Microsoft XML” (MS-XML), OOXML, or EOOXML. There are now several papers about problems with OOXML. Groklaw’s EOOXML objections has lots of good information. Edward Macnaghten’s Technical Distinctions of ODF and OOXML: A Consultation Document (ODFA UKAG) is interesting because it shows what actual documents look like using the different specs - and it exposes a lot of problems in MS XML that have not been widely discussed before. Sam Hiser has an interesting ODF / OOXML comparison as well. Rob Weir has interesting comments as well.
Perhaps a more elegant demonstration the OOXML is absurd is this picture of their 6000-page spec, printed. This is a single spec; no wonder there’s been so little review compared to OpenDocument. Yet even with this hideously large size, MS XML (OOXML) still fails to give the important details that a spec really needs. The reason it’s so hideously long, while still failing to give the important details a spec needs, is simply because they ignored a vast number of standards - so they end up re-inventing lots of already-existing standards. Thus, they end up conflicting with a large number of different standards. They even ignored MathML, a widely-used standard that even they supported, and redid things from scratch.
Even on the ground this pressure for OOXML makes little sense. Magazines like Science and Nature reject Office 2007 documents. Macintoshes still can’t read the .docx (etc) format, nor can Pocket PCs.
I guess one good result is that Microsoft has encouraged voting for OpenDocument, because that’s the only logical thing it can do if it really believes that having “many conflicting formats are a good thing”. In contrast, there’s no reason that someone who wants a truly open single format needs to vote for OOXML. It’s perfectly reasonable to reject OOXML on the grounds that it conflicts with an already-existing ISO standard (OpenDocument). If there’s something that OOXML does that OpenDocument doesn’t, it would be much easier to add that tweak to OpenDocument, because OpenDocument builds on existing standards while OOXML fails to do so.
Microsoft is not a “universal evil”, and I praise them when they do good things. But encouraging multiple conflicting standards for the same area is not a good thing. In some sense, I don’t care if MS XML or ODF become “the” format for office documents, as long as the final specification is truly open. But the materials noted above lead me to believe that MS XML is not really open; it appears to be effectively controlled by one vendor, both in its current and future forms, as one obvious example. So MS XML isn’t really an option, and we already have a nice working solution.
What I want is a single document format that is fully open. What’s that mean? See Is OpenDocument an Open Standard? Yes! to see what the phrase “open standard” really means. And let’s look at it in practice. Currently I can edit text documents using the program “vim”, and I don’t even bother to ask if the other person uses emacs, or Notepad… just by saying “simple text format” we can exchange our files. Similarly, I can edit a GIF or PNG file without wondering what originally created the file - or who will edit it next. That’s generally true with other standards like HTML, HTTP, and TCP/IP. That’s the beauty of open standards - real open standards enable a thriving industry of competing products, allowing users to choose and re-choose between them. I want to see that beautiful sunlight in office suites as well.
path: /misc | Current Weblog | permanent link to this entry