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

[robert_weir@us.ibm.com]

I agree with you on almost all of your points, but I'd frame it 
differently.

First, the use of XML provides extensibility.  This is an undeniable 
benefit of the technology.  However, this is not the same as saying the 
ODF standard should define conformance to allow extensions beyond the 
schema defined by the standard.  These are two different things.  One does 
not imply the other.

You properly use the example of HTML as an format where useful extensions 
have been made.  But when you look at the XHTML Recommendation, you'll 
find that it only defines strict conformance, and in fact states that 
mixing XHTML with other namespaces is not conformant (section 3.1.2). 
Certainly the fact that XHTML does not allow extensions in conformant 
documents has not prevented innovation?

We can't prevent extensions, and we shouldn't try, IMHO,  Extensions, at 
least where the user has some control over where and when they are used, 
are powerful tools. But the user does not have control if they think they 
are using ODF but their word processor is putting undocumented, 
incompatible and non-interoperable extensions into their documents. 

That said, I'd be less adverse to having both strict and loose conformance 
classes if we also required that ODF Producers have a mode of operation 
where they would create only strictly conformant documents.  Then that 
puts the control back into the user's hands as to what mode they want to 
operate in.

-Rob

David Faure <faure@kde.org> wrote on 01/20/2009 01:02:34 PM:


> 
> 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 
functionalitywhere 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).
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>