Re: [oiic-formation-discuss] Summary and Focus?

[Simon Calderson <caldersons@yahoo.co.uk>]

----- Original Message ----
From: Sander Marechal <sander.marechal@tribal-im.com>
Subject: Re: [oiic-formation-discuss] Summary and Focus?

> Marbux wrote:
> > I.e., an implementation of an ODF desktop word  processor profile
> > (more featureful) that opens a document generated by an implementation
> > of a subset ODF web app editor profile (less featureful) would process
> > the document as though the latter were the superset. The document can
> > then be edited in the more featureful app and sent back to the less
> > featureful app in a vocabulary the less featureful app can understand
> > and process correctly.
> 
> Simon pointed out to me that what CDRF defines as profiles is something 
> different than a subset profile that could be used as an interop 
> specification, but the idea itself has merit I think, even when it's got 
> nothing to do with CDRF.

The idea Marbux points out isn't really interop; it can't be because it only works in a single direction as described (which isn't what CDRF mandates in any event). If you have a super-set and a sub-set spec., if you create a document on a super-set processor, how is that going to work on the processor which only understands the sub-set? What if it contains content specced only in the super-set? Unless you know in advance you're sending a document to the less featureful app, it's not going to work.

That kind of interop is basically baloney; it's not interop to say "here is a smaller, simpler specification which represents a least common denominator", because any time you go beyond that LCD your interop is blown out of the water. It's a sham; it's another file format incompatibility except you put the onus on the user ("you didn't save it in the right profile, so it's your fault it doesn't work").

For me, an ODF profile is sensibly going to be more like the following:

* separating out the standard into different areas of interest. You could reasonably do this as CDRF profiles: e.g., your basic word processor is the profile "ODF text + ODF tables + ODF styles + XLink + DublinCore", for example (grouping by XML namespace).
* acknowledge that ODF word documents will usually contain the stuff in the profile, but could have extras, e.g. ODF script. Interop here is about graceful degradation for those parts you don't support: you don't throw them away, but maybe there are specific rules about editing you have to follow (perhaps parts become uneditable, perhaps the whole thing realistically - e.g. if the thing was an interactive doc. with forms, you can't sensibly do anything with it).

So it's not just about specifying some LCD - though that should be a part - but also specifying behaviour when you encounter stuff you can't deal with. That way, there is no "Basic ODF" and "Full fat ODF" - there's just ODF, and interop is how less featureful apps degrade when faced with stuff they can't handle.

I think this whole issue is different to one of general ODF interop, though. That's about making sure that apps which support the same features do roughly the same thing with the same document. This other interop is about making sure apps which _don't_ support the same features also play nice. Marbux has very specific concerns, which are now highlighted by the fact he's only interested about interop with non-ODF foreign binary junk, witness the Google doc posted to this list. I don't care much for what he's pushing.

Thanks



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html