[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]