Microsoft and Standards
Microsoft’s amusing standards stance | Perspectives | CNET News.com: In this article, Håkon Wium Lie speaks about the current office document format standards disagreement.
Written from the perspective of someone who has been involved in the W3C standards process for the Web, Lie recites past Microsoft acts in regard to standards, advancing the view that the purpose for pushing OOXML is to cause both standards to fail. He believes that this was the reason that CSS and XSL stylesheet languages both are underused on the Web today: that Microsoft introduced XSL in order to prevent standardized markup and stylesheets from displacing their proprietary HTML tags.
Consumers never wanted the choice between VHS and Beta, and mobile telephony in the United States was hindered by customers having to choose between competing standards.
That is an interesting theory. As Lie mentions, customers didn’t ask for the VHS vs. Beta format war in videotape cassettes. It was not in their interest to have their investments in hardware and content at risk depending upon which side finally gained market ascendancy. Likewise, it is my opinion that the HD-DVD vs. BlueRay format war is not in the consumer’s best interest (but then, both are designed from the start with TUR, certainly not at all pro-consumer). And again, introducing a second “standard” format for office documents is not in the end-user’s interest either. The reason is purely for competitive reasons: vendor lock-in, to maintain the Microsoft monopolies in office applications suite software and client operating systems for another several years.
Choice soon turns to frustration when your rented video doesn’t fit in the slot, or your phone doesn’t connect. People want to choose products based on price and performance, not on underlying equivalent standards.
This is something that is not lost on Microsoft. Because the two standards (OASIS ODF: ISO/IEC 26300:2006 and OOXML: ECMA 376/ISO DIS 29500) offer equivalent functionality in the same area of applicability, end-users, that is individuals and enterprises, will only want to deal with one of them. If that one is ODF, the injection of choice into the market is very likely to deflate the fat profits in at least two of Microsoft’s major business units. If OOXML is that one, Microsoft has ensured that no one else can be fully compatible, so they will continue to keep control of users’ computers and their documents.
In this conflict, ISO must answer a difficult question: is there room for both ODF and OOXML inside ISO? I’m not a fan of either format, but ISO should be concerned about the closeness of the two formats. They are similar in function, solving the same problems and using XML as the syntactic foundation. While it’s healthy to have competition between different standards, it’s rarely productive to have competing standards within an organization.
In view of the fact that ODF was designed from the start to be compatible with multiple vendors’ applications, able to contain the necessary data from each of those applications, including their implementations of legacy binary formats such as .doc and .xls, it is clear that “preserving legacy data” as an excuse for a separate format just will not wash. Lie wraps up with a plea, “Microsoft–please–if you think standards are so important, why not start using them?“
Rick Jelliffe, no stranger to XML standards and injected into the middle of the dispute by Microsoft’s Doug Mahugh, believes that Lie was “dodgy” on details. He agrees that the best way to exchange basic document contents (the actual data itself) is W3C-standard XHTML.
On this last point, Lie has a great line: speaking of ODF and OOXML … I’m no fan of either specification. Both are basically memory dumps with angle brackets around them. Lie thinks this is a bad thing; I think it is a necessary thing: sometimes you want to only save what can beread everywhere (the case with HTML save) but usually you want to save everything that is in your document so that when you next open it, it is exactly the same publication you saved
Memory dumps are bad. They violate the basic ideas of object-oriented programming. You want to specify an interface (in this case, a file format) that you will support. However, the details of how you support it (your in-memory data structures and your translation between the two) should be completely separate, so that you can change or improve your implementation at any time without breaking any dependencies. This is first-year computer science.
I’m not a programmer, although I occasionally have to whip together a little something to assist in my daily tasks. Whenever I have said, “It will not matter if I go ahead and serialize my data structures to a file; I’m only using it for this one thing,” something changes and I need to access that data with a different set of memory structures. It is as certain as night following day. You can bet on it: the requirements will change in an unpredicted manner. For that reason, you always want a neutral, extensible interface (in this case file format).
Jelliffe pokes at Lie for leaving out details, then objects to one detail that was specified (number pages in the format documents).
But Lie is right, I think, to be alarmed by the prospect that if OOXMLfails MS will revert away from open formats. I don’t see them adopting ODF as the default format for general sale. for a start, current ODF simply does not have matching capabilities. This issue of fit is strong enough that we don’t even need to get to the issue of control. We have this nice little window now where MS is inclined to open up its formats, something that the document processing community has been pleading for for years. The ODF sideshow runs the risk of screwing this up; I’ve said it before, but I say it again: being pro-ODF does not mean you have have to be anti-OOXML. ODF has not been designed to be a satisfactory dump format for MS Office; OOXMLhas not been designed to be a suitable format for Sun’s Star Office or Open Office or IBM’s products. HTML is the format ｏｆ choice for interchange of simple documents; ODF will evolve to be the format of choice for more complicated documents; OOXML is the format of choice for full-fidelity dumps from MS Office; PDF is the format of choice for non-editable page-faithful documents; all of them are good candidates for standardization, all have overlap but are worthwhile to have as cards in the deck of standards. But systems for custom markup trumps all.
We all have our dreams. My dream begins with someone from the state lottery calling me. Rick’s dream begins with OOXML joining with lots of other good little standards in a fairy tale wedding down at the Justice of the ISO. The only thing is, it is merely a fantasy. Just as VHS eventually killed Beta, one of the two office document file formats will eventually drive the other one to extinction, as they really serve the same purpose, so only one is necessary. In biology-speak, they both fit into the same ecological niche, and thus the success of one will come at the expense of the loss of the other.
This is a generational change in computing. Keeping users bound inside of a company-specific format (which OOXML is, no matter how someone “spins” it) is intended to keep the next generation of software firmly under the control of one company. A standardized, vendor-neutral format, on the other hand, will free users from subservience to the Wizard of Redmond, who sits brooding in his dark castle, and his minions.
I, for one, hope to see Minnesota and Texas amend their acts to specifically refer to and specify OpenDocument Format. I hope to see California, New York, Florida, and other populous states follow suit, leading to an express train of document format conversions (all of them from closed proprietary formats to open formats such as ODF).