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
- From: robert_weir@us.ibm.com
- To: oiic-formation-discuss@lists.oasis-open.org
- Date: Thu, 26 Jun 2008 11:44:59 -0400
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:
http://www.robweir.com/blog/2008/01/interoperability-eliza-way.html
-Rob
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]