Re: [office] ODF 1.2 Single-Level Conformance and Law of Unintended Consequences

[David Faure <faure@kde.org>]

On Monday 19 January 2009, robert_weir@us.ibm.com wrote:
> David Faure <faure@kde.org> wrote on 01/19/2009 02:10:28 PM:
> 
> > 
> > On Monday 19 January 2009, robert_weir@us.ibm.com wrote:
> > > Since current implementations do not (to my 
> > > knowledge) introduce foreign attributes and elements into documents, they 
> > > would not be impacted by this change.
> > 
> > By foreign, do you mean attributes and elements not defined by ODF?
> > Then I beg to differ, there are plenty of these, see below.
> 
> We talking about ODF 1.0 and ODF 1.1, section 1.5 Document Conformance, "
> Documents that conform to the OpenDocument specification may contain 
> elements and attributes not specified within the OpenDocument schema." 
> We're considering restricting this. 

I would like to know why exactly. The whole point of using XML and not a binary
format is to make such extensions possible, and just like I can write additional
attributes (or even comments) in HTML that webbrowsers will ignore (but that
a specific tool could interpret), koffice should be able to write koffice-specific
attributes in an ODF document, as long as these do not affect interoperability.

> > * KWord can define the behavior of a frame when a new page is 
> > created (for DTP-like usage
> > where you might want a similar frame to be created on the next page 
> > at the exact same position;
> > another one use case is a company logo in a page corner for instance).
> > This is done with koffice:frame-behavior-on-new-page in the frame 
> > style; and here again it
> > only affects further editing, not rendering of a given document.
> 
> Yes, I believe so.  Would it be too much trouble to eliminate these in 
> KOffice as part of supporting ODF 1.2?  For example, can they be expressed 
> using another ODF mechanism? 

Not that I know. And since it's too late for new proposals for 1.2, the idea
that "any extension should be standardized" doesn't hold. It doesn't hold in general,
anyway -- this idea kills innovation and forces everyone to implement the exact
same thing. You have to understand that if an office suite decides to use
ODF as its **NATIVE** document format, not some export functionality where some
data could be lost, then ODF _has_ to provide a way for that office suite to
save anything it wants to save into the document, even things that might not be
standardized... :
- ... due to lack of interest from other implementors
- ... yet (to be standardized in a future version but not standardized yet)
- ... because the attribute is used for very internal reasons, sometimes even
to _increase_ interoperability (e.g. in KOffice we have to create a wrapper frame
to map a koffice feature with valid ODF, but we better recognize it as such so that
we don't actually show it in KOffice). All such cases where the view of things in
one app differs slightly from the view of things in another app, are reasons
for such extensions, which are not necessarily harmful to interoperability,
on the contrary.

> Although in your particular case, these may be benign and not effect 
> rendering, you can see how in general this mechanism can easily be abused. 

So for fear of abuse you want to forbid any kind of extension? This doesn't
make sense to me. Remember "innocent until proven guilty"? :-)

>  It is hard enough for an implementation to ensure interoperability with 
> what ODF does actually define, without having to also worry about what 
> another implementation might add to an ODF document which is undefined.

But that's the point: other implementations are NOT supposed to care for
those extensions. If they feel the need to do that, then indeed those extensions
should be standardized instead.

Don't get me wrong, I'm all for standardizing as much as possible, but this TC
has to realize that this isn't always possible. Are you saying that we would accept
ANY feature request? Obviously not. So if we don't accept something in ODF,
and we don't find a compromise that would make everyone happy, what's going to
happen? Either the implementors requesting it will drop the idea altogether (right...)
or they will just go ahead and use an extension for it. But since nobody else
in the TC wanted that feature, why would we care? Something that only
exists in one application cannot by definition be interoperable in the first place,
that's not a document format issue, that's an application feature set difference issue.

If it's still valid for KOffice-2.0 I will try to get you all to accept an equivalent
of koffice:frame-behavior-on-new-page in the next version of ODF, but meanwhile
the use of extensions will have to stay, obviously. And things like referring to
a style from another style, well, I'm having some trouble to get the similar
"user-defined character and paragraph styles" accepted...

-- 
David Faure, faure@kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).