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


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

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

Subject: Re: [oiic-formation-discuss] Proposed Use case -- Interoperability invertical and horizontal ODF markets

Simon Calderson <caldersons@yahoo.co.uk> wrote on 06/26/2008 10:55:29 AM:

> Dave Pawson <dave.pawson@gmail.com>:
> > 2008/6/26  <robert_weir@us.ibm.com>:
> > >
> > > In any case, the ODF standard does speak to foreign elements and
> attributes,
> > > so an exhaustive test suite will of course include examples of
> this feature.
> > >  Since the ODF standard says that such content should be
> preserved, we would
> > > check to see if that recommendation was observed and issue a
> "warning" if it
> > > was not.
> >
> > 1.5 requires them to be preserved. That's a fail not a warning
> 1.5 lists that as a "may" here - you are allowed to throw away non-
> ODF content, and indeed that's what OOo does.
> I'm really unsure of how this is an interoperability issue, though.

Well, it would be an interoperability issue for any implementation that extends ODF with undocumented, proprietary markup in a foreign namespace.  
But I don't know of any implementation that does that today.  And do we really want to encourage these type of extensions by granting them specific interoperability guarantees?  

When Paul talks about "round trip" interop you need to look very carefully.  This has roots in the former OpenDocument Foundation's failed "da Vinci" project, which was an attempt to write an ODF plugin for MS Word.  They planned on storing proprietary MS Office formats as opaque markup associated with the ODF content.  So, if Word had a list style that could not be represented perfectly in ODF, then they would make a best-fit mapping to ODF and then also store the original Word list definition as essentially a blob in a foreign namespace.  So this information would be unusable to anyone else in the word, except to the da Vinci plugin, who could look at it when the document returned into MS Word.

So their model for interoperability was doomed to fail unless every other ODF application in the world was forced to add extra code and extra complexity in order to store away their proprietary extensions to ODF, extensions that no other application could take advantage of, since they were undocumented.  That is why they have then, and continue now to push for changes to the ODF standard that would require ODF applications to preserve proprietary extensions to the format.

I rejected that model of interoperability then, and I do so again today.  You do not improve interoperability by storing information in a form that other applications cannot understand.  That is a move in the wrong direction. I can't prevent someone from extending ODF, but hopefully we can avoid legitimizing such extensions and forcing other applications that are not themselves extending ODF to suffer the cost of preserving these extensions in order to claim conformance with the ODF standard.

A did a blog post on this topic a few months ago which may explain the logic a little better:  



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