Well, ODF does nothing for them now in regard to interoperability except in terms of one-way trips to more featureful applications. ODF simply has such lax conformance requirements that only 1:1 feature mapping between apps can enable round-trip interoperability. So "match features with the application you want to interoperate with" is the implicit current message from the TC, although as I recall Patrick said that bluntly.
It doesn't have to be that way. E.g., WordPerfect since version 6.0 (now at 13.0) has provided both backward and forward non-lossy round-tripping of documents among WP versions regardless of feature mismatches using a scheme very similar to the ODF foreign elements and attributes. (The .wpd <unknown> tags.) But you can't achieve lossless round-tripping between less and more featureful apps if conformant apps are allowed to destroy metadata needed for interoperability. That would be like programming the latest version of WordPerfect to destroy rather than process the <unknown> tags. Any ODF app in the chain of document exchange that destroys such metadata (like OOo does with foreign elements and attributes other than its own and paragraphs and text spans) breaks round-trip ability.
Such an approach could be enhanced by use of profiles for different levels of support/application types, e.g., lightweight web editors. We think the W3C Compound Document Framework's conformance section takes the right approach here:
<
http://www.w3.org/TR/2007/CR-CDR-20070718/#conformance>. E.g., "A conformant user agent of a superset profile specification must
process subset profile content as if it were the superset profile content."
Or as Tim Bray of Sun put it back in 2005 in the context of resolving the MOOXML/ODF incompatibilities:
"The
ideal outcome would be a common shared office-XML dialect for the
basics—and it should be ODF (or a subset), since that's been designed
and debugged—then another extended vocabulary to support Microsoft
features , whether they're cool new whizzy features or mouldy old
legacy features (XML Namespaces are designed to support exactly this
kind of thing). That way, if you stayed with the basic stuff you'd
never need to worry about software lock-in; the difference between
portable and proprietary would be crystal-clear. And, for the basic
stuff that everybody uses, there'd be only one set of tags.
This outcome is technically feasible. Who could possibly be against it?"
<
http://www.tbray.org/ongoing/When/200x/2005/11/27/Office-XMLToo bad the Sun folk in Hamburg never got that memo. :-) Of course, Bray's suggestion is very close to what the Foundation and Novell proposed to the TC five different times, including three versions that had been signed off on by Massachusetts ITD. But Sun's illustrious Mr. Brauer never put a single one of those
proposals on the TC agenda's action items, which will be another issue ODF 1.2 will
have to face at ISO. And now we all know what the refusal to enable ODF app-MS Office interop led to, just as we predicted. <
http://www.linuxworld.com/news/2007/072307-opendocuments-grounded.html
>.
Of course when you have the ODF app with the overwhelming user uptake trashing interop
metadata, the net effect is to cement that app's position in the ODF application market
by ensuring only one-way interop with it absent a 1:1 feature match in
another application. It works well for Microsoft and it works well for Sun.
Why did you think Sun
is so determined to retain discretion to destroy metadata xml:id
atttributes? I'm still waiting to hear the first use case exposing the need to
destroy metadata xml:id attributes except by user-initiated action. And precisely what is that "right thing" Sun promised you to persuade you to abandon your objection to permission to destroy xml:id attributes, Bruce?
E.g., did you get anything other than RDF bibliographic support in OOo?
We're focusing our MS Office interop work on CDF now instead of ODF. Should this TC ever decide to require interoperability, we can fairly simply add a profile for the ODF formats. In the meantime, we can begin connecting Microsoft Office to open formats actually designed for interoperability, giving users the ability to bypass MOOXML and Sharepoint Server.