Andy is funny. It is actually draft 1.3 (1.0 was the baseline submission). The table-of-contents is 97 pages and you can get the overall information in the first 550 pages of the document (thought there are still incomplete portions). Then there are reference sections that include element-by-element, attribute by attribute definitions.

The parts I like are the conformance section and the Annex A on Interoperability Issues, where they will catalog every feature that has implementation-defined characteristics that must be defined by a conforming implementation. Strict conformance and (non-strict) conformance are clearly defined, including what a (non-strict) conforming implementation must make available, how it must provide warnings on detecting or producing documents using extensions, etc.

I think Andy’s post reflects the common tension between assured interchange and interoperability and the use of a format (e.g., XML itself) as a foundation for innovation and variation on a common substrate. It’s probably a good depiction of why one size doesn’t fit all.

My sense is that, in taking the legacy preservation route, this is what OOX has to look like. If ODF is to end up being the laboratory for exploratory development of office-format variations, it will be valuable that there are also OOX and PDF for strict preservation of editable and non-editable document forms over extended time. ODF may also be appealing to developers for new entrants since the conformance bar seems to be lower. On the other hand, repurposing and adding custom material to OOX documents will be popular. Thank heavens for XSLT, huh?

Meanwhile, ConsortiumInfo is commenting now on the first Ecma draft of Open XML, and specifically on whether it’s over-specified!

There is no change in the OSI Draft International Standard 26300 (ODF) document that was balloted. It included the May 2005 ODF specification without changes. I don’t know whether there were ballot comments that might need to be resolved before the 2-month formal-standard ballot that should be next according to the OSI road-map (http://nfocentrale.net/orcmid/blog/2006/05/congratulations-odf-osi-draft.asp).

I agree. I think compatibility test suites and profiles will be very important, especially in government agencies and institutions that are required to employ competitive procurement of standards-conforming products.

Your observation about the likely need for profiling ODF features is a good one. Except for the formula syntax issue, I’m not familiar with which features are implemented across the board consistently wrt interpretation, and which are underspecified (or even dying on the vine, like parts of W3C XML Schema?). Development of in-house styles and plugins for enforcement will also be key, of course for improving interop/interchange.

Versioning issues might eventually be another worry, but of course that’s SOP for procurement of office suites now (with MS Office kind of the poster child for this).

I struggled wiht ODA — and ASN.1 — at one time and I actually had a mutually unrewarding call with Charlie Goldbfarb about why Xerox wanted to abstain on HyTime (because of the SGML hub document being serious overkill). Last I heard, about 10 years ago, someone wanted to switch from the ASN.1ODA-like format we used to using a unique XML format. Odd, considering that thepayload consisted of 600 dpi page-sized raster images.

I think there are going to be big interchange challenges between ODF-compliant applications, and it would be great if serious work began on that, so that adopters could specify profile requirements for procurement qualification. I think the same situation that made WS-I important is with us here too. I put off blogging about that, but I think it is almost soup now.

I have no way or desire to predict whether Gartner’s assessment is right; I was observing that if you accept their analysis, then their recommendations are perfectly reasonable. In fact, it was the wording of their recommendations in particular that brought to mind the old discussions of how to achieve successful interchange and presentation independence, two requirements that content developers across time have often shared.

I do not mean to advocate in any way what ISO should do, and in fact have nothing to do with ISO activities (though I did attend a meeting of the group that worked on SGML and DSSSL once more than a decade ago). To my very minimal knowledge, they have no rule against approving multiple specifications that treat similar areas of technology. And I am active in OASIS, which has at times hosted multiple committees working on similar technologies.

I would be cautious about the prediction in the Gartner analysis and elsewhere that acceptance of ODF as an ISO Draft International Standard precludes acceptance of the eventual ECMA Office Open XML Document Interchange specification. This is a complete misreading of actual rapid-adoption practice for the ISO ratification of standards produced by member standards bodies (OASIS and ECMA included) and of what is meant by “standard” at this level. (For example, do you think that the existence of ECMA and ISO ratification of C# specifications and the CLI would prevent Java from being processed through either ECMA or ISO? This might well, in fact, be an useful move at this point in the determination of an approach for open-sourcing Java.)

Finally, it is strongly advisable for individuals involved in standards activities, especially those whose participation is sponsored by competing firms, to avoid suggesting or appearing to advocate that any standardization activity in some way precludes someone’s technology from becoming the subject of standardization.