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

[robert_weir@us.ibm.com]

Thomas Zander <zander@kde.org> wrote on 06/28/2008
02:24:16 PM:

> On Saturday 28. June 2008 19:52:53 marbux wrote:
> > > Round trip with an application that does not support ODF
seems a dead end
> > > Paul.
> >
> > Disagree. That's what the foreign elements and attributes parts
of the
> > ODF spec were designed for.
> 
> Thats not true, that usecase is only possible by accident. Instead
that part 
> was designed for allowing an implementation to have a feature that
is not 
> (yet) in ODF.
> For example FooWord can have a new draw: feature where it shows on
screen a 
> logo but only saves one tag instead of saving the whole svg.  FooWord
may 
> choose to save that as </fooword:logo> instead of in the draw
namespace.
> 

That is the primary use case.  Of course, the
ODF standard does not pass moral judgement on what the extensibility mechanism
can be used for.  It is a tool and can be used for good or evil.  It
is a technical facility.   But because we cannot control what others
put in foreign attributes and elements, applications must be free to implement
their own policies on whether to discard or preserve such markup.  Does
it contain interoperability hints?  Or does it contain private user
metadata?  Does it contain data for a new feature in another application?
 Or does it contain a virus?  Is it storing content from my last
20 delete operations?  Or is it storing child pornography?  The
fact is, I don't know and cannot know.  A reasonable, and even recommended
practice would be for an application to drop any markup that is in a namespace
that it does not understand.  The contrary position, that your application,
in order to claim conformance, must play the mule for whatever data, useful
or harmful, innocent or illegal, that some other application wrote into
the document, this is ridiculous.

> The important distinction here is that other ODF implementations canread
99% 
> of the doc.  So, marbux, your disagreement is based on a misunderstanding.
> ODF is not meant to be used for a document created by an application
that 
> does not support ODF.
> 
> Any support for that usecase is purely coincidental and not a supported
> usecase of ODF.  It certainly looks like its off topic for the
proposed TC.
> 
> To OASIS; is there some code-of-conduct that
people have to abide by on the 
> OASIS mailinglists?  I see the mails from Paul have a returning
theme, they 
> put into bad light respected members of our community. The continued
> bad-wording of those respected people makes me weary of replying and
of 
> sharing my experiences here.
> 
> ps. for people that don't know me, I'm a core-developer of KWord,
the word 
> processor of KOffice. The often used quote to describe KOffice is
that its 
> the second main ODF implementation.

Btw, thanks for joining the discussion, Thomas.  I
know we have a number of implementors lurking on the list.  But I'm
afraid that few of them have the stomach to deal with the bullying, the
personal attacks and the constant barrage of legal threats that accompanies
participation in this list.  

When the actual OIIC TC is created, we'll be operating
under Robert's Rules of Order (in addition to OASIS TC policy).  Rules
of order provide a balance that guarantees the minority the ability to
be heard, in a deliberative process, while also allowing the majority to
express their will.  I believe, that the TC Chair(s), OASIS staff
and OASIS Board of Directors have sufficient tools at their disposal to
ensure that this balance is respected, once we have a TC. 

In any case, if you have a few minutes, I think we
would all be interested in your thoughts on how best to improve interoperability
among ODF implementations.  From your KWord perspective, what would
give the biggest "bang for the buck"?  Test suites?  Conformance
tests?  Profiles? 

-Rob