David Faure <> wrote on 01/20/2009 02:59:55 PM:
>
> I know that it's not koffice you're afraid of here, but certain
hugecompanies
> 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
to
> 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.
-Rob
