But this also meant that the ODF internal plug-ins for MS Office had to match the performance and quality of the Microsoft internal OOXML plug-ins. This is not an impossible task. Where ODF failed in Massachusetts is not with the internal ODF plug-ins, but with the big ODF application vendors' refusal to support da Vinci, which was the only internal MS Office plug-in whose developers were willing to go the ODF Community route former Massachusetts CIO Louis Gutierrez desired.

The da Vinci plug-in could be released within a few weeks if the only goal was to add virtually perfect native ODF support to MS Word. But that is insufficient to establish interoperability with other ODF applications such as OpenOffice.org. That is because Sun Microsystems, which absolutely controls the OpenDocument standard development process, has programmed OpenOffice.org to destroy all but two of what section 1.5 of the ODF specification refers to as "foreign elements and attributes" and is busily making sure that the new RDF metadata features in ODF v. 1.2 will not be dependable for interoperability purposes. See, for example, this thread on the ODF Metadata Subcommittee mailing list.

So now we have Massachusetts and Denmark recognizing both OOXML and ODF as open XML file formats. More governments will follow. The problem with that recognition is that the internal Microsoft OOXML plug-in is the only cost effective (free) and non-disruptive way for existing MS Office-bound workgroups and workflows to move to XML.

The truth is, the big ODF application vendors left governments with no other choice but to go with OOXML as the only way to migrate existing systems to XML. They hoped to capitalize on ill will against Microsoft and legislation forcing rip-out-and-replace migrations. But as the Massachusetts situation, the state legislation situation, and the situation in Denmark shows, government IT establishments are beginning to rebel against the foolhardy and expensive rip-out-and-replace strategy.

The bottom line: The best remaining hope for Open Document Exchange Formats now lies with the European Community. At a conference on Feb.28 to March 1, 2007, IT representatives of 21 European Community national governments laid out their demands for industry. It was in effect an announcement that neither ODF nor OOXML were acceptable, that they expect Microsoft and the big ODF vendors to collaborate on development of a single harmonized set of formats, with ODF providing the common features. The summing up at the plenary session says much about the likely end game in the office document file format war:

-- There is a general dissatisfaction with the perspective of having competing standards.

-- One format for one purpose: Administrations should be able to standardize (internally) on a minimal set of formats.

-- No incomplete implementations, no proprietary extensions.

-- Products should support all relevant standards and standards used should be supported by multiple products.

-- Conformance testing and document validation possibilities are needed -> in order to facilitate mapping/conversion.

-- Handle the legacy/safeguard accessibility.

Europe is now openly threatening to use the government procurement power to force convergence of ODF and MOOXML. The question is whether the big vendors will bow to what the market requires.

But what is perhaps most remarkable about the situation is how thoroughly standardization organizations like Ecma, OASIS, and ISO have failed to protect software users' interests from big vendors' efforts to maintain separate office productivity software markets, divided by incompatible file formats. It's time for the Free and Open Source Software community to develop its own office document standard, along the lines of what Europe has demanded.

A new set of formats, perhaps based on a wedding of XHTML+, CSS 3.0, and RDF, or perhaps an interoperable enhancement of ODF, is in order. This is clearly what the EU IDABC has in mind with their recently announced Open Document Exchange Format proposal -- ODEF. The amazing thing is that the internal plug-ins can produce ODF, XHTML+, and ODEF. The internal plug-in architecture is how those not aligned with the big vendors can neutralize big vendor control over both applications and standards.

The big vendors had their chance and blew it. Now it's time for the demand side of the equation to pick up the pieces and go for the universal interoperability demanded by a real world convergence of information systems needing to perfect the high fidelity exchange of portable XML documents.

Sad, isn't it?

Edwards and Martin are respectively, president and director of legal affairs for the nonprofit OpenDocument Foundation, which is affiliated with the developers of the da Vinci plug-in discussed in this article.