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 in vertical and horizontal ODF markets


On Thu, Jun 26, 2008 at 8:44 AM,  <robert_weir@us.ibm.com> wrote:
>
> 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.

Materially misleading. The documentation you refer to is not in the
ODF standard and is irrelevant to any profile work on this TC other
than to further demonstrate that compatibility with the standarrd
itself must be broken to do the profile-related work proposed for this
TC. There are ODF apps aplenty that write app-specific extensions to
ODF. The fact that documentation for *some* of them recently arrived
in the ODF TC email archive says nothing at all about what must be
done in this proposed TC's profile related work to establish interop
between apps that extend the adopted standard and are incapable of
writing to unextended ODF.

OOo and Lotus Symphony are examples. You simply play word games to
avoid discussing the technical merits of my use case and the interop
issues it exposes.

 And do we
> really want to encourage these type of extensions by granting them specific
> interoperability guarantees?

You're the one who wants to keep granting conformant status to
app-specific extensions to ODF. That's nailed to the wall deeper than
you will ever escape from. See your passioned defense of that in this
thread, despite the law I briefed for you on that subject.
<http://lists.opendocumentfellowship.com/pipermail/odf-discuss/2008-April/thread.html#7276>.

The issue relevant to extensions raised by my use case is whether the
proposed OIIC will be required to create a compatibility framework
that lets everyone round-trip tag soup ODF documents without data
loss.

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

Entirely Irrelevant to the merits of my use case which relates only to
the interop of ODF implementations other than to demonstrate that
round-tripping without data loss is feasible even if apps don't share
the same file format. The roots of this go far farther back than the
da Vinci project, e.g., the WordPerfect compatibility framework that
allows all versions of WordPerfect from 6.0 through 14.0 to round-trip
documents without any data loss at all, despite unforeseen features in
the later versions.

The technology to round trip documents without data loss between apps
with different feature sets, even ones that use different formats, is
well understood and has been for a very long time. That is what the
ODF foreign element and attribute provisions were designed for.

Your "Interoperability the ELIZA way" article is nothing but an appeal
to ignorance. How about disclosing the specs for the IBM Workplace
compatibility framework for the import-export and conversion of
non-ODF formats? Let's see how IBM processes unrecognized metadata and
round-trips documents.

You offer nothing but evasions to avoid discussing the merits of my
proposal. None of your responses address those merits at all, let
alone in the context of what you and Sutor said about interop
requirements in horizontal and vertical markets within the context of
a single standard. .

Smoke, mirrors, and double standards, Rob. That's all you've brought
to the discussion of the merits of my proposal. .

Best regards,

Paul
-- 
Universal Interoperability Council
<http:www.universal-interop-council.org>


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