First draft of ODF 1.2 out

By Rick Jelliffe
February 17, 2009

ODF editor Patrick Durusau has announced the availability of the first committee draft of ODF 1.2 Part 1. He comments (to the ODF TC in the first instance)

Do note that this means we all need to re-double our efforts to proof and resolve any issues (remaining or otherwise) that we see with the text.

ODF 1.2 is re-organized, and adds some new features such as RDF metadata and several revisions. ODF 1.2 has been "feature frozen" for a while (a year?) now; I don't know whether the draft has had all the changed decided by the ODF TC folded in yet.

Like the OOXML standard, the text includes various auto-generated cross-reference information that could be stripped out for a minimal version of the standard (more suitable for printing.) Unlike the OOXML standard, there is no example or tutorial material, nor standard graphical objects or built-in styles and so on.

Part 2 of ODF 1.2 will be OpenFormula. Part 3 will be the material on ZIP and packaging.

At the moment, the ODF TC has an interesting discussion going on about conformance issues. Readers will remember how many of the pupported deficiencies claimed against OOXML by supposed boosters of ODF turned out to be also true of ODF. For example, OOXML was regarded as bad because it was extensible (which allowed all sorts of imagined embrace-and-extend tactics); but it turned out that ODF also allowed arbitrary foreign elements and so on.

There was also a problem with interpreting ODF's foreign element system as well: readers may remember an issue I found that the OpenOffice people had interpreted the spec to mean foreign elements (and children) could be completely stripped while it actually meant (it seems) that the children should be unwrapped.

I pointed out several times that only by making a profile restricting features could there be any hope of interoperability of the kind desired by many adopters.

In the latest draft, there are two profiles (conformance levels, or whatever you want to call them), one just requiring that the XML sub-documents defined by ODF do not contain any foreign elements, and then one that allows foreign elements.

In 2006, even before OOXML was submitted to ISO, I wrote about a concern I had with ODF in this regard:

The ability to create extensions or subsets willy nilly is the antithesis of a standard. It is the difference between "I bought product X because it says it supports standard Y but it often fails and I am pissed" and "I bought product X because it says it has partial support for standard Y and I accept it doesn't work completely." ... In practise in Open Formula, they seem to be doing things the right way, and are having conformance levels: well-defined groupings of functionality in clear namespaces.

It seems that the minimal profile is driven by two different concerns: users who want to make sure that there is a common bar that all implementations can be expected to reach reducing the possibility of embrace-and-extend, and vendors of OpenOffice codebase systems, who are happy if ODF freezes with a feature set that co-incides with OpenOffice's, excluding extra features by competitors. The opposition to the minimal profile seems to come from vendors who have harmless extensions (why remove value-adds? it only makes user experience worse) and some non-institutional users, who don't see that it achieves much (this is my reading, please read the OASIS ODF TC archives for more info, always being aware that we are not privy to private exchanges.)

I think it is really good to have the two conformance levels.

However, they won't do what some people may want them to do. In ODF, even in the strict conformance level of the draft, there are at least three alternate ways to do markup apart from just plonking in foreign elements: a developer/vendor who wanted to add its own extensions could just put the information in another subdocument (external markup); the developer/vendor could use the new RDF metadata; and the developer/vendor could use or abuse existing tags, such as the document-settings elements or bookmarks.

The only way to have guaranteed lockout is to have *all* attribute values explicitly specified in the schema, and no foreign XML sub-documents (unless used by XForms.) This is of course ridiculous. If we are at the level of paranoia, we also need to further develop profiles of media binary formats too, since they sometimes allow arbitrary metadata where the malevolent developer could park their toxins.

So why are the two conformance levels (even though limited) still good to have? Postel's law.

I think in the short-term, something like MCE would be better, and more workable, which I wrote about earlier this week. However, MCE does not prevent inventive evil vendor/developers any more than ODF's draft strict conformance level can.

What MCE gives is having your cake and eating it too. It recasts the issue as one of, rather than saying that nothing goes or anything goes, that as long as there is a fallback to a minimal standard version, it is harmless to have alternate content which may have vendor-specific extensions. Rather than setting up an antagonistic attitude to vendors, it neutralizes the problem. (A data capture application could easily have various settings, such as history, that allow a more consistent user experience between editing sessions, but which subsequent stages can safely throw away, for example.)

None of these systems is entirely perfect. As I wrote earlier a fortnight ago (in an entry I don't think made it to the XML.COM syndication) Conformance classes should mirror stakeholder usage clusters. A minimal conformance class, such as the draft specifies, is a pretty blunt and brutish thing, but that is not to say that it cannot have some appropriate uses.

Where the new draft gets it right, I think, is that it does not define two classes of ODF consumer. I hope there is no effort to alter s1.4.4 so that an ODF consumer is allowed to reject a document with foreign elements or attributes. (Certainly it can notify the user however.) MCE would be much better.

The danger with banning extensions, apart from the futility of doing it, is that ODF can be frozen as RTF-in-angle-brackets, a kind of state-of-the-art format representing a set of functionality found in 1990s word processors, and blocking out the kinds of smart documents, high-value markup, and boundary-crossing documents that may be useful: consider an ODF document that was also an XBRL document for example. Because of the feature freeze, I don't expect that MCE would make it into ODF 1.2 (and I expect some stakeholders wouldn't feel comfortable raiding OOXML's larder for various reasons.) But it is worthwhile considering as a possibility.

[Update: In other words:


  • Implementation mismatches (e.g. vendor makes up home-made profile)=bad for interop;

  • Vendor provided extensions=bad if circumvents standard, but there are many harmless and useful extensions;

  • Stakeholder-group defined 'standard' profiles (e.g. PDF/A)=useful;

  • Mere banning foreign elements= useful class of documents, but defeatable;

  • So the trick is how to neutralize the problem to cope with all the stakeholder needs, so that vendor extensions don't cause implementation mismatches: MCE alternate content is good approach (this approach similar to how mail readers handle HTML and plain text alternatives); alternative content is a smarter solution to meet Postel's law.]


You might also be interested in:

News Topics

Recommended for You

Got a Question?