[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 Unintended Consequences
On Tuesday 20 January 2009, email@example.com wrote: > 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? I chose a rather poor example. Things are quite different with HTML and browsers, in fact, because the most common case is that the person or application creating the document is completely separate from the application rendering the document, so indeed there is a need for strict compliance and only writing out things that independent renderers (the web browsers) will be able to render. And, HTML documents are mostly readonly, there are typically no editing-related settings in them. On the other hand, with OpenDocument, the most common case is that the application creating the document will be the one editing it again, with of course the possibility to view and edit the document in other applications (interoperability), but there is a real use case for application-specific settings, *especially* those that affect editing rather then rendering, like those I presented. This is more related to a nice user experience with the application than it is related to actual interoperability -- the equivalent features might be very different in the GUI anyway. Because of this need for editing-related settings in OpenDocument files, I see no reason for forbid application-specific extensions. Yes, if people store additional *content* in extensions then that content won't appear in other applications, this is obvious, and the people doing that will break interoperability, and shouldn't do it. But extrapolating from there to "all extensions are forbidden" breaks a valid for use case for extensions: editing-related settings (and really-application-specific settings). > 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. The user doesn't have to care, as long as the extensions don't break interoperability. If they do, then indeed it's bad and affects the user. > 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. This doesn't make sense to me. "Save as ODF without koffice:foo attributes" would only give you the exact same document, with less features if you reopen it in koffice, and with the exact same features if you reopen it in other ODF apps... I know that it's not koffice you're afraid of here, but certain huge companies 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. -- David Faure, firstname.lastname@example.org, sponsored by Qt Software @ Nokia to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).