Microsoft OOXML- why is it so wrong?Apr 30, 2008 · 3 minute read (archived post)
OOXML; Office Open XML. Even the name is false as it clearly isn’t ‘open’ in the sense of non-discriminatory, particularly against GPLed implementations. It’s not at all clear whether a GPL implementation of OOXML can be done.
Then there’s the specification itself. 6,000 pages at the first round, growing to something like 8,000 after the BRM. The sheer number of technical errors, failure to incorporate other ISO standards in the appropriate places, and downright contradictions should have ruled out the specification from becoming a standard. That Microsoft shoved this standard into the ISO Fast Track by getting ECMA to rubber stamp it shows a complete disregard for the standards process. Technical committees the world over agreed that the standard shouldn’t have been fast tracked.
Then there is the fact that it probably isn’t possible to implement OOXML. Microsoft Office 2007 doesn’t implement it contrary to what the popular IT press reports, and it’s unlikely to be implemented in Office 2008 (at least on Macs). So even Microsoft doesn’t think so.
So what it the point of this “standard”? Microsoft has expended vast amounts of time, and money, on countless countries’ technical review committees on a standard that it won’t implement. But perhaps it reveals the true purpose of why it did it. Microsoft certainly doesn’t want standards that other organisations can implement as it damages Microsoft’s potential for lock-in. By changing document formats with every version of Office, it can essentially dictate the upgrade cycle to the market and guarantee it’s office monopoly and revenue stream. By producing and getting standardised a fundamentally broken format it again gets to set the agenda for the document format. If we let them.
One oddity is that Microsoft repeats this mantra of choice. They say that customers should have a choice of document formats, and by standardising DIS 29500 (OOXML) they are simply providing customers with a choice. It seems reasonable on the face of it; shouldn’t customers have a choice of document standards?
One way to look at that question is to ask; shouldn’t there be a choice in electrical plug sockets? Shouldn’t there be a choice in the way the pedals are laid out in a car?
Each of these examples provides a clue to whether document formats should come in may different formats for the same type of document. There are many different appliances that plug into electrical sockets and there are a great variety of different cars. In each case the customer benefits from having a single standard, but has the choice from many implementations of the standard. This is a good thing; multiple pedal layouts on cars would be bad from a safety and cost perspective. Manufacturers would have to support multiple standards so that customers would get the style they need; and certain cars would only come in one standard which would prevent some customers from being able to drive those models.
Multiple implementations of a single document standard are good for the customer. Plenty of choice, the ability to match features to price and the sure knowledge that the document will always be available. But it’s bad for Microsoft as it bypasses their lock-in.
Microsoft repeats that customers should have a choice and equivocates choice in standards with choice in products. I want a single standard and multiple implementations to choose from. Then our documents can be used by everyone regardless of their product.