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

marbux <marbux@gmail.com> wrote on 06/27/2008 12:15:37 PM:

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

Please forward a single example of document written by Ooo or Lotus Symphony that includes foreign attributes or elements according to the ODF standard, section 1.5.  I have not seen this occur before, it it would surprise be greatly to see an example.

If I had to guess, you are confusing foreign attributes and elements in section 1.5 with the "Application Settings" defined in section 2.4.  These have nothing to do with each other.

As to the technical merits of your proposal, I'm sorry, I must have missed them.  Could you explain briefly exactly how preserving the nonexistent proprietary extensions that ODF applications today are not writing will help improve interoperability?


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