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

[robert_weir@us.ibm.com]

marbux <marbux@gmail.com> wrote on 06/26/2008
06:55:04 AM:

> I propose that, amongst other tasks, the OIIC TC be tasked with
> providing a set of profiles that clearly and unambiguously specify
the
> conformance requirements essential to solve the following use case.
> 
> 1. DEFINITIONS and MARKET CONDITIONS:
> 
> Market A is that for ODF mobile device editors and all competitors
in
> that market each have unique implementations of ODF that support ODF
> to varying degrees.
> 
> Market B is that for ODF web editors and all competitors in that
> market each have unique implementations of ODF that support ODF to
> varying degrees. The range of ODF features supported in this market
is
> broader than that in Market A.
> 
> Market C is that for ODF outliner editors and all competitors in that
> market each have unique implementations of ODF that support ODF to
> varying degrees. The range of ODF features supported in this market
is
> broader than that in Market B.
> 
> Market D is that for medium-capability ODF editors, e.g., KOffice,
and
> all competitors in that market each have unique implementations of
ODF
> that support ODF to varying degrees. The range of ODF features
> supported in this market is broader than in Market C.
> 
> Market E is that for the most featureful ODF editors and and all
> competitors in that market each have unique implementations of ODF
> that support ODF to varying degrees. The range of ODF features
> supported in this market is broader than in Markets D.
> 
> In each of Markets A through E, each competitor's ODF implementation
> writes application-specific foreign elements and attributes in the
> application's unique ODF namespace and is incapable of writing to
> unextended ODF.
> 

Interesting scenarios Paul, but I'm not aware of a
single ODF implementation out there today that actually "writes application-specific
foreign elements and attributes in the application's unique ODF namespace
and is incapable of writing to unextended ODF".   Are you?  Certainly,
ODF allows applications to write out extensions in their own namespace.
 But do we actually see this happening anywhere today?

I'm hoping the overall goal of the proposed TC, as
stated in the eventual charter, will include something along the lines
of "To improve interoperability among ODF implementations".  If
so, we'll want to limit ourselves to the problems that actually exist among
ODF implementations.  We'll have enough of those to worry about that
I don't think we'll also have the leisure to tackle the problems that don't
exist as well.

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.

Personally, I'd be in favor of deprecating the use
of foreign attributes and elements altogether, or at least limiting its
use severely.  With ODF 1.2 metadata we have a preferred framework
for extending ODF, a framework that does not rely on foreign attributes
and elements.  

-Rob