OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

David Faure <faure@kde.org> wrote on 01/20/2009 02:59:55 PM:
> I know that it's not koffice you're afraid of here, but certain 
> who are known "embrace and extend" and not care much for writing out
> files with "undocumented, incompatible and non-interoperable 
> extensions". I know.
> But whether an extension is good or bad, is not something that a simple
> validation against an XML schema can tell us. It's something we'll have 
> discuss between humans.

I'm not asking to distinguish good from bad extensions.  I agree that this 
is a question beyond what a standard can speak to.  My point is purely 
that of conformance.  Should ODF define conformance such that an extended 
document is conformant?  This is not because of concerns about any single 
company or product.   My preference is that _all extension_, "good" or 
"bad", result in a non-conformant document.   Or at least start from that 
point and then add back the minimum required rather than have no ceiling 
at all.

Remember, there is nothing that says a non-conformant extensions cannot be 
used and be useful.  In fact that is a common way in which a standard 
evolves.  Someone prototypes an extension, and once it works submits that 
proposal to a standards committee and then sees it included in the next 
version of the standard.  No guarantees, of course, that the proposal will 
be accepted.  But holding back the label of "conformant" is the primary 
way to bring vendors to the table to propose and document such features. 
If we just label everything conformant, than why would a vendor trouble 
with the time and effort to get their proposals accepted formally into the 
standard?  Why buy the cow when you can get the milk for free?

But your point on editing hints versus content extensions is well taken. 
Maybe there is some way we can formulate a conformance clause that takes 
account of that.  But I'd rather have an extension framework that handles 
things like that in a structured way than to allow any XML anywhere.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]