As you will recall, Alex was the Convener of the (in the opinion of  many) controversial Ballot Resolution Meeting (BRM) held in Geneva, Switzerland in February of 2008. That meeting was the crucial and penultimate stage in the OOXML adoption process (you can find a resource page I set up on the BRM, its consequences, and commentary on both sides of the issues here). For those who did not follow this drama, OOXML is an XML-based document format standard created by Microsoft and initially approved by the Ecma standards body, while ODF is the OpenDocument Format (ODF) developed by standards developer OASIS.

Part of what allowed OOXML to achieve a positive vote at the BRM was a series of promises that Microsoft made during the lengthy adoption process. Those promises were meant to address concerns over Microsoft’s true intentions relating to OOXML. For example, some suspected that Microsoft’s primary objective in achieving ISO/IEC adoption of OOXML was to cancel out any advantage that ODF might have gained when it earlier achieved that status.  Would Microsoft in fact actively support OOXML after it had been approved, or would future versions of Office include (for example) proprietary extensions, or not support the finally adopted ISO/IEC standard at all?

These concerns were sharpened by the fact that Microsoft did not, at the time that OOXML became ISO/IEC 29500, have a version of Office available to sell that would be compliant to the ISO/IEC standard. This was not surprising, because numerous changes were made to the original version during the approval process. Instead, Office mostly complied with the original version of OOXML that Microsoft had first submitted to Ecma, and which had been rejected, in a first vote on the standard by the ISO/IEC working group.

Thus, after the dust settled, there were two versions of OOXML in existence: the Ecma-approved “Transitional” version that Microsoft was implementing, and the “Strict” version that was adopted by ISO/EC on April 2. Unless Microsoft committed to adopting the Strict version, however, the ISO/IEC standard would be almost worthless, since there would be little market for third party products that were not interoperable with Office.

With that by way of background, let’s turn to Alex’s post, which is significant because Alex was tasked with being no mere parliamentarian in managing the BRM – the primary reason being that there were thousands of issues which had been raised and which needed resolution at the BRM. Addressing and discussing each one in a single week would have been impossible, and Alex brokered a number of decisions that (depending on your viewpoint) either made a creative resolution possible or made a sham out of the BRM process. Up until now, Alex has staunchly defended those decisions.

As Alex states in the introductory part of his blog entry:

The key breakthrough of the revision process was the splitting of the specification into two variant versions, called “Strict” and “Transitional”. The National Bodies confined all the technologies they found unacceptable to the Transitional format and dictated text to be included in the standard intended to prohibit its further use:

“The intent […] is to enable a transitional period during which existing binary documents being migrated to DIS 29500 can make use of legacy features to preserve their fidelity, while noting that new documents should not use them. […]

This annex is normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions. The intent is to enable the future DIS 29500 maintenance group to choose, at a later date, to remove this set of features from a revised version of DIS 29500.”

Alex writes that this decision was crucial to securing approval of OOXML:

Enough National Bodies could then vote in good conscience for OOXML knowing that their preferred, Strict, variant would be under their control into the future while the Transitional variant (which – remember – they had effectively rejected in 2007) would remain purely for the purpose of accurately specifying old documents: a useful aim in itself.

The balance of Alex’s post (which you should obviously read in its entirety rather than relying on this partial summary) constitutes a “report card” for several of Microsoft’s promises. After reviewing Microsoft’s conduct during the two years that followed the BRM, Alex finds it wanting in important respects.

More specifically, Alex concludes:

1.  Conformance with the Strict Standard: Alex cites Microsoft’s commitment to implement the Strict version, but concludes that it has not done so to date. He states that “On this count Microsoft seems set for failure….Microsoft are behaving as if the JTC 1 standardisation process never happened,…” Alex also cites a number of third party reviewers of the current version of Office who have reached a similar conclusion.

2.  Maintenance: Alex notes that while defect reports were frequent in the beginning, they have since tailed off. Similarly, action on defect reports has also languished in many cases. Alex also states:

Most worrying of all, it appears than Ecma have ceased any proactive attempt to improve the text, leaving just a handful of national experts wrestling with this activity. It seems to me that Microsoft/Ecma believe 95% of the work has been done to ensure the standard is “useful and relevant”. Looking at the text, I reckon it is more like 95% that remains to be done, as it is still lousy with defects.

(To be fair, Alex has also been critical of defect resolution in ODF as well.)

Alex speculates on where within Microsoft the problem lies, and then proposes what needs to happen next. But he notes that, regardless of the cause, if Microsoft ships Office 2010 without full support for the Strict version of OOXML, it “should expect to be roundly condemned for breaking faith with the International Standards community.”

Alex concludes, though, that Office 2010 will not in fact be compliant. He therefore makes a number of recommendations, including some that fall into the “buyer beware” category, and some which are directed towards an attempt to still achieve Office compliance with the Strict standard. Interestingly, he also suggests that:

Any assurances Microsoft has given to regulatory bodies (such as the EU Commission) about standards conformance must be looked at very carefully giving full consideration to the circumstances of this release.

Alex’s final conclusion is bleak:

In short, we find ourselves at a crossroads, and it seems to me that without a change of direction the entire OOXML project is now surely heading for failure.

It’s not easy to look back at decisions that you helped to form and conclude that they may have been ill-conceived, or at least bad bets. I applaud Alex for the candor that he shows in this blog entry, and for sharing the details that only first-hand participants in the ongoing OOXML maintenance process would know.

Which leaves, of course, one question remaining: with no general awareness of the facts, will Alex’s blog entry drop like a pebble into the pond of the Internet, leaving few, if any ripples? Or will others pick up on it?

If the latter, then one must assume that Microsoft will have little or no incentive to still comply with the Strict version of OOXML, and the whole ODF-OOXML saga may prove, at last, to be less a gripping drama than a simple farce.

sign up for a free subscription to Standards Today today!