And this is just the first draft 
               Microsoft spokesperson, commenting on the 4,000 page
               first draft of Open XML, as quoted at

The first draft of Open XML has been posted for public viewing at the >Ecma Website, five months after Ecma accepted Microsoft's submission of what was then less-appealingly referred to as the XML Reference Schema.  The most detailed source of information I've found so far is this page at Brian Jones' blog, which focuses heavily on XML in Office and the development work on Open XML file formats (Brian is a Microsoft Office Program Manager who has frequently provided public comments on the progress and purpose of Open XML).  You can also find short press articles at >NetworkWorld.com, by IDG's Elizabeth Montalbano, and at by Peter Galli.  Both Elizabeth and Peter have been following the ODF/XML Open story for many months. 

According to Jones, the specification is now 4,000 pages long (roughly twice its original size) and has been the subject of weekly two hour conference calls and three day face-to-face meetings about every two months. 

Each of these sources is quite brief, and therefore there is little new information to be gleaned about the draft specification, short of downloading it and diving in yourself.  For those not so able or inclined, though, here is one out take from Brian's blog that is instructive regarding the differing approaches (and constraints) represented by the ODF and the XML Open approaches:

Depth of documentation – I know we’ve said this a million times, but this is a huge project. Migrating all the existing Office documents into an Open XML format and then providing full documentation is a ton of work. Many people don’t realize how large these applications are, and how much there really is to cover. If you want an example, download the spec and look a the documentation for the simple type “ST_Border” which starts on page 1617 (it’s in the WordprocessingML reference section under simple types). That shows a list of almost 200 legacy border patterns that you can apply to objects in a Word document. Tristan Davis, the Word representative on the Technical Committee, had to wok on every single one of those and provide images so anyone else could reproduce them. He created almost 200 documents, took screenshots of each one, and then provided the description and image representation in the spec. This format is 100% compatible with the existing base of Microsoft Office documents, so nobody will need to worry about losing features, even if it’s the “Maple Muffins” border style (page 1643) 🙂

That’s a lot of detail – much more than can be found in ODF.  As I’ve noted before, a key decision in the creation of any standard is the level of detail to standardize upon.  If the level is too low, then interoperability will suffer, because much of what is needed to make the product useful is left up to the vendor, and those additional features will be proprietary. 

But if the level is too high, then only clones can be built, which is good for interoperability, but death to innovation.  It can also be death to competition, since if (as in this case) the standard is based on an existing product, then no would-be competitor would ever expect to be able to catch up with the incumbent, much less compete on price.  So why bother?

While I’m not a programmer, what version 1.3 of XML Open indicates to me is that the specification may be fine (and even perhaps very good) for making it possible for end users and external developers to do more with Office documents, but it may be useless for creating true competition in the marketplace – which presumably is exactly what is intended.

As a result, if what you are looking for is multiple product alternatives, a rich set of features, price competition, and rapid, market-responsive product evolution, then I think that products that support ODF will be what you’ll want to be looking at.

I’ll return to this topic in the days ahead as more information becomes available.