OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] OpenDocument TC coordination call minutes 2007-08-13

On 8/13/07, Bruce D'Arcus <bdarcus@gmail.com > wrote:

On Aug 13, 2007, at 4:20 PM, marbux wrote:

> It's already defined in JTC 1 Directives along with some pretty
> exacting bottom line interoperability requirements that ODF v. 1.2
> fails miserably. E.g., the discretion for implementations to destroy
> metadata xml:id attributes and foreign elements and attributes.

The examples you posted of a definition of interoperability aren't
really all that helpful. They are too general. What does it *really*
mean in practice -- for ODF or any office document format -- to adopt
the following definition?

"For the purpose of this policy statement, interoperability is
understood to be the ability of two or more IT systems to exchange
information at one or more standardised interfaces and to make mutual
use of the information that has been exchanged."

... or this:

"Standards designed to facilitate interoperability need to specify
clearly and unambiguously the conformity requirements that are
essential to achieve the interoperability."

Does it, for example, mean that ODF cannot ever introduce a feature
that all implementations -- including non-ODF implementations such as
MS Office -- do not support? It seems to me that's the upshot of your
position. What does that do for small lightweight tools that want to
claim to be ODF compliant?

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-XML

Too 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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]