OOXML: by Microsoft, for Microsoft

The ODF Alliance has some new documents, including this one from Oracle [PDF] [via Groklaw, Bob Sutor]

There are a number of fairly large scope changes that are the result of proposed changes from Ecma. Worse yet, the actual changes will not be known until some time after the BRM (when the editor releases the final draft), and will not be available for in time for national bodies before they must make a final decision on the specification.

Oracle is not the only company which protests against OOXML at the moment. Other large companies speak out and this includes Google, which comes to show that ODF is not a case of just Sun and IBM (no matter how much the likes of Dennis Byron want it to seem that way). In fact, merely all support for OOXML is paid for by Microsoft. This includes Novell. It's pseudo-support. It's manufactured consent.

Out comes Red Hat with its latest protest against OOXML.

As the March 29th voting deadline on OOXML approaches, Red Hat has announced its support of Open Document Format (ODF) instead of Office Open XML (OOXML).

[...]

Regardless of the complexity of the specifications, it is thought that OOXML is not currently defined enough to be fully implementable by those without access to inside information. ECMA, for example, acknowledges that additional information is necessary for compatibility with legacy application settings, and promises that the information will be made available. While it’s helpful to acknowledge the limitations of OOXML, we think it is unfair to ask the nation bodies, as members of ISO, to approve an incomplete standard. Given the lack of interoperability and inadequate review, Red Hat is asking members of ISO to vote “No” to OOXML this month.

Mind the fact that Red Hat, Oracle and Google don't bother to even mention the corruption surrounding OOXML (e.g. [1, 2, 3, 4, 5]). They concentrate on technical aspects alone. So does IBM's Rob Wier in this latest writeup of his.

I sometimes hear it said that OOXML, or ODF for that matter, are simply XML serializations of particular applications' native representations. This is said, seemingly, in an attempt to justify quirkiness or outright infelicitous file format representations. "We had not choice. Office 97 did it that way, so OOXML must as well". This variety of technological determinism indicates poor engineering judgement, laziness or both.

An easy counter-example is HTML. Does HTML reflect the internals of NCSA Mosiac? Does it represent the internals of Netscape Navigator? Firefox? Opera? Safari? Are any faults in HTML justified by what a single browser does internally? Applications should follow standards, not the other way around.

[...]

What is the engineering justification for this [OOXML] horror? I have no doubt that this accurately reflects the internals of Microsoft Office, and shows how these three applications have been developed by three different isolated teams. But is this a suitable foundation for an International Standard?

This rhetorical question should only be answered by those who are not paid by Microsoft -- either directly or indirectly -- to respond or to vote. ⬆