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 Unintended Consequences


On Tuesday 20 January 2009, robert_weir@us.ibm.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, faure@kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).


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