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: Fri, 27 Jun 2008 13:10:18 -0400
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?
-Rob
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]