ODF has no equivalent *elements* to the customXML tags that allow foreign markup by indirection. However, it doesn’t need them, because it allow foreign markup directly, and allows applications to strip them (which is what OpenOffice does, for example): where is the significant difference between the formats for guaranteed interop?

(This is complicated because OpenOffice implemented this in a way that makes it useless for wrappers. However, tables and sections could presumably be used, instead.)

The aspect of this is that it seems a bit strange to criticize a general feature that is specifically designed to allow value-added documents to participate in custom toolchains that they impair interoperability. It is like saying that the pen impedes interoperability because it may be used to write in Mongolian, which few people can read.

Interoperability is not the be-all and end-all of qualities for a document format. Customizability and extensibility are useful things, in their place.

So it seems to me that the question should be whether the customXML features are useful or appropriate or optimal for a certain case (or class of cases), rather than blanket statements. I think I am allowed to have different use cases, and therefore features, to you, aren’t I?

“This custom XML is an insidious trick in my opinion as it makes documents non-interoperable. As soon as you use custom XML via Word 2007 you are guaranteeing that information will be lost when you share documents with OpenOffice.org users and potentially users of earlier versions of Word.”

You should learn more about something before you make a big fuss about it.

First, it is entirely a question of the *consumer* of this information as to whether the custom XML gets lost. In the case of older versions of Word using Microsoft’s free add-on to read and write OOXML, THE INFORMATION IS NOT LOST. The “write” part of the add-in preserves any such information.

As for Open Office not preserving it (if it does so, I don’t know), the fault is with OpenOfiice, not with Word or with the OOXML ability to embed custom XML. Talk to them about it.

As for the general argument that the custom XML in IS29500 documents acts to reduce interoperability, you are simply wrong, for two reasons:

1) Applications that consume and generate IS29500 (OOXML) documents, if properly written, are supposed to ignore (not strip out) any such custom XML if they don’t understand it. So, the custom XML is totally invisible to such applications.
2) For applications that are specially written to consume or generate a specific variety of custom XML, the ability to have such XML embedded in ordinary office documents acts greatly to IMPROVE their specific kind of interoperability.

So, the end result is: improved interoperability, with no downside.

You should rethink your attitude towards this matter after you have checked out the facts first.

In most scenarios people have a specific schema in mind for tagging the content of the document, so with the styles approach you end up imitating XML structure through nested styles. That can get very complicated, and can cause interop issues for consumers that don’t handle nested styles well. I like the microformats/customXml approach because it’s simple for developers to work with, and consumers that don’t care about custom semantics can just ignore it without losing any formatting (as would happen if styles were ignored). It’s also easy to round-trip the customXml element, since it’s in the WordprocessingML namespace.

if I’ve understood this issue correctly; OOo has an equivalent to custom xml files, but there’s no interop because both MS and Sun converters chuck them away? I know you’ve mentioned that OLE objects offer better interoperability, and I’ll look at how we might transcode for that.

jim