I really don't have anything to do with Office XML formats so can't contribute much of substance to the debate over Massachusetts' draft Enterprise Technical Reference Model v 3.5 which mandates the OASIS Open Document Format. This has generated a lot of weblog posts, mostly from open source advocates or employees of Microsoft competitors fulsomely praising it and hoping that this political decision will give their preferred technologies more economic clout.

A couple of more independent assessments raise issues that I find more interesting. For example, Stephen O'Grady acknowledges that Microsoft (or third parties) could easily support the ODF format is there is a business need to do so.  That gets to the  question of whether Massachusetts' very real needs for document interoperability and longevity are best met by the XML familiy of technologies in general, or one specific format in particular.  MS Office and OpenOffice / StarOffice have taken different paths here. Office 2003 can handle custom XML schemas and stylesheets quite dynamically, whereas OO has been hard coded to handle a specific schema, and the latest beta versions have evolved to support the OASIS ODF.  It's not at all clear to me why supporting specific schema(s), whether or not they are endorsed by a standards body, is considered more "open" or "standards based" than support for the more fundamental XML, XML Schema, and XSLT standards that Office 2003 implements. 

One technical note - one can't simply configure Office 2003 to handle OASIS ODF documents directly because the OASIS Technical Committee chose to define that format using the RELAX NG schema spec (endorsed by OASIS and ISO) rather than the W3C XML Schema spec, the W3C Recommendation and which  Office 2003 supports.   There are some plausible technical reasons for this in that RELAX NG is simpler, based on a more solid formal underpinning, and somewhat better suited for defining complex textual document formats than is W3C XML Schema.  Unfortunately, that advantage does not carry over into tool support (few mainstream XML editors currently support RELAX NG validation) or support for structured data within the text.  For example, tools that support the popular data-oriented XML programming technique known as data binding (which allows XML to be parsed easily into instances of application-level programming objects rather than abstract node trees) almost all require W3C schemas as input.

This gets to a second issue, raised by Joe Wilcox (and something I debated at length in previous O'Grady postings):

Considering the OpenDocument format is only truly supported by OpenOffice 2.0, which isn't even available yet, I'm at a loss to see how the XML-based format meets the Commonwealth's goals for openness or backward compatibility. Nobody's really using the format yet, right? How, uh, open is that?

My other problem is one of definition. Looks like the Commonwealth considers Adobe's PDF as open, because the spec is openly published. OK, I'm scratching my head, because if you download Corel's WordPerfect SDK the WPD specification is right there. As for Microsoft, while I'm grumbly about the company's liberal use of open, I have to say if PDF meets the Commonwealth's standard so should Office formats; at the least the XML-based formats coming with Office 12. Microsoft does publish its XML schemas and license them on a royalty-free basis.

There have been all sorts of inconclusive debates about the real meaning of terms such as "standard" and "open", and I don't want to go there.  It's important, however, to appreciate that there is a very real distinction between a specification ratified by a committee or standards organization, and a "standard" that enables real-world interoperability.  MS Word's binary format or PDF are usually considered "de facto standards" in the sense that one can reasonably expect a random correspondent to be able to read a document in one of those formats.  Obviously we can do better, and  almost all concerned believe that moving to some sort of openly documented XML format is a better way to achieve short term interoperability and long term usability of documents.  In general, the more eyes that have helped debug a spec and the more organizations have endorsed it, the more of a real standard it will be. But there are plenty of examples of standards organizations producing specifications that have not led to real world  interoperability of any significance.  W3C XLink,  OASIS WS-Reliability,  and ISO HyTime are clear examples of this in the SGML/XML world.

The important thing to remember is that industries, not industry standards committees, are the ones who produce industry standards.  Knowing many of the people who helped produce OASIS ODF, I expect it to be a carefully crafted and good-quality specification, but it has to prove itself capable of solving real-world problems before it can legitimately be called an industry standard.  For example, its reliance on RELAX NG makes it pleasing to XML geekdom, but greatly complicates the processing task for most actual developers. Will  the mainstream be diverted by the need to support ODF documents, or will ODF remain in a backwater?  Good intentions don't often make for successful policies.

Bismarck supposedly said ""People who enjoy eating sausage and obey the law should not watch either being made".  That applies to industry standards, which we enjoy once they've been "cooked", but get produced by a messy process at best.  It's easy to sympathize with Massachusetts' desire to buy its document standard sausage only from nice clean  kitchens that use wholesome cruelty-free ingredients, but I've spent too much time in the XML standards sausage factory to believe it until I taste it. 

Tofu bratwurst for the Labor Day picnic, anyone?