Having been involved in all of those conversations (which Paul was not, by his own choice), I cannot recall a single engineer who agreed with Paul and Gary’s view. In fact, the strongest voice against their position in the end was Thomas Zander, who is one of the lead developers of KOffice. Hard to pin that entirely on Sun, then, or “big vendors.”

I’m certainly biased, but I am optimistic that the new RDF support in ODF 1.2 will provide room for enhancing interop. But as I’ve said recently, this is about much more than just document format specs. Office 2007/2008 has citation and bibliography support, for example. But AFAIK, no third-party extensions actually use it. There are probably many reasons for this, but one big one is the inadequate API that MS exposes.

Peter, I’m with Ian on the fact that IS29500’s custom XML support is every bit as well-defined as OLE embedding is. I agree with your point that it’s messy for two different editing applications to round-trip documents with custom markup in them, especially if the document is edited in both apps, but that’s not the typical use case I’ve seen in custom XML scenarios. The tagging of content is usually done immediately before some type of automated processing by a non-desktop app, so the issue of what an editor should do with that markup doesn’t come up very often.

As for whether custom XML is a thinly veiled plot to lock people into Word, I think another way to say it is that Word is the richest implementation of custom XML concepts in a word processing application today. We would love to have other implementations support these concepts as thoroughly as we do, exactly as they’re specified in IS29500 and ECMA-376, and I think many organizations would get great value out of the resulting interoperability. We’re the proud owners of the first fax machine, but the protocols have been standardized, wires have been strung between towns, and we’re looking forward to more fax machines coming online soon.

You said that:
“That’s because OLE objects are embedded using standard interfaces not vague hand-wavy whatever-you-like Custom XML.”

You seem to think that the following are either undefined or non-standardized:

1) The method of embedding a custom xml schema in the OPC container for an OOXML document
2) The method of tagging words or sections in the body of a document, for the case in which those tags are from the custom XML schema.

Neither of these are true. They are both clearly documented as part of the IS29500 and ECMA-376 standard.

Those methods are INDEPENDENT (sorry for the shout) of the particular custom XML schema used. It is not that custom schema that defines the embeddings; it is the IS29500 or ECMA-376 standards. If the former were true, then you would have reason to worry, because there would indeed been no standardized way of handling the interoperability of such documents.

So, you can see why the use of custom XML in OOXML greatly *increases* the interoperability for applications that consume, produce, or modify files that make use of the hundreds of standardized XML vocabularies that have been defined for specific domains of knowledge. When you combine this fact with what I showed in my earlier comment about no loss of information by conforming applications that do not understand the specific custom XML vocabulary, then you come to my main conclusion: a big win for interoperability overall.

I hope this helps.

“The information is written out into OOXML then when you open it in an earlier version of Word you can’t see it. I tried this with the NLM plugin and as far as I recall there was no structure apparent if you open the file in an earlier version of Word. The result is that if you try to edit the document you break the structure at which point THE INFORMATION IS LOST.”

Just because no structure is *apparent* in another application doesn’t mean the information is lost. As long as you don’t inadvertently (or deliberately) destroy the information, it won’t be lost. To prove that, all you have to do is re-open the edited document in Word 2007, and voila – the schema is intact and all tagged terms are still tagged.

Repeat the following experiment, which I just did a minute ago, and then you will understand:

1. Install and configure the ontology add-in to Word 2007 on one PC.
2. Create a Word 2007 document that uses a term in one of the ontologies you said to use during the configuration of the add-in.
In my case, the entire document was the sentence: “I have potter syndrome.” (“Potter syndrome” is a term in the Human Diseases ontology.)
3. Save the document as a Word 2007 file.
4. On another PC that has an earlier version of Word (in my case, Word 2003) and that of course has the “Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats” installed, open the Word 2007 file.
5. You will see that it doesn’t recognize the term (just as you mentioned).
6. Edit the document in some way.
In my case, I made 2 copies of the sentence, so I had three copies overall. The first I left intact. The second, I changed the words “potter syndrome” to “blah blah”. The third, I added the word “don’t” to the sentence, so it now read “I don’t have potter syndrome”. So, my document now read:
I have Potter syndrome.
I have blah blah.
I don’t have Potter syndrome.
7. In Word 2003, save the edited document in Word 2007 format.
8. Open the edited document in Word 2007 on the original machine.

According to you, the information is destroyed. Well, it isn’t.

To be specific:

- The schema is still there, intact, which is easily verifiable if you have the Developer tab installed.
- The first, unedited sentence is still recognized by the ontology add-in as containing a recognized term (potter syndrome) with all its tags and meanings.
- The second sentence (which has “blah blah”) is not recognized as using the custom XML (because it doesn’t).
- The third sentence, which says I don’t have potter syndrome, is recognized as having the “potter syndrome” tag. Everything is fully functional.

So, the information is NOT DESTROYED (sorry for the shouting!).

This fact shows that the custom XML feature in IS29500 is *not* a trick.

In my humble opinion, it finally realizes the original vision of SGML in the 80’s, in that it provides a way for office documents to contain custom vocabularies (which can, of course, also be ones covered by international standards). That GREATLY increases interoperability between applications that need to consume, produce, or transform information in those custom vocabularies. There is no *inherent* information loss in OOXML applications like Word 2003 with the Compatability Pack (i.e., not counting deliberate user destruction of information) that are properly written not to destroy any custom schemas or custom schema tags.

As for OpenOffice, talk to whoever maintains it. From what you have said, it is not a properly conforming OOXML application in that it destroys the information. But that does not take away anything I have said.

There was a fiery battle over it and Sun ignored all requests for a use case exposing the need for the change, but the Sun proposal was duly rubber-stamped by the big vendor-dominated ODF TC.

Gary Edwards and I resigned from the TC on that occasion, which was only the latest in a series of TC decisions on ODF 1.2 that broke interoperability with MS Office. Two notable prior examples are the switch from ordered list tuples to list triples, and Sun’s refusal to even place on the TC agenda five Novell proposals aimed at compatibility with MS Office.

So I don’t understand Doug Mahugh’s optimism about RDFa support in ODF 1.2, particularly since the Sun “should preserve” language appeared to be directly aimed at blocking the use of RDFa to work around the destruction of (conformant) foreign elements and attributes by OpenOffice.org in order to create MS Office ODF plug-ins that can interoperate with OOo.

My sense is that these issues will get fixed at ISO/IEC JTC 1 after ODF 1.2 gets there. But between the time it takes to get ODF 1.2 through JTC 1 and the lag time before JTC 1’s changes are implemented, we’re probably talking about a multi-year delay in interoperability.

I think it vitally important that people realize Microsoft is not the only big vendor who misbehaves in regard to document format standards.