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: ODF Conformance

On Wednesday 04 February 2009, you wrote:
> Hi David,
> I'm wondering how your thoughts are currently regarding ODF conformance, 
> and the discussion on the TC list.
> If I understand correctly, originally you were concerned that the new 
> conformance language would eliminate some extensions that KOffice wrote 
> into documents.  Michael's latest proposal allows extensions in 
> <style:*-properties> and under <office:meta>.  Does that address your 
> concerns?

Yes, I think so. Well, I found a case where we added a custom attribute to
draw:frame, but obviously we could move that into its style and then it would be a
<style:*-properties> extension. Code-wise it was much easier to set it as an
attribute of the draw:frame though (and here again it was _for_ interoperability,
not against it - the "dummy" frame is created so that other OASIS applications
can render this case correctly, and the attribute is there so that KWord removes
the dummy frame on loading since _it_ doesn't need it).

But most people on the list seem to think that "extensions" == "loss of interoperability",
including you:
> However bad you think interoperability 
> would be in that case, you must admit that it is made worse, not better, 
> by extending the documents with private schemas. 

This is sometimes true, sometimes not, as in the above case where the producer
transforms something into standard OpenDocument at writing time but needs
a flag to recognize this at loading time as something it can render in a better way
than the "standard" way. Or in the cases that Dennis detailed.

To put it simply: yes, extensions kill interoperability *if* the things written out as
extensions were supposed to be interoperable (or if they really get in the way,
like in <foo:bar> example). But sometimes that's not the case, carefully written
extensions are useful and harmless. We want those, and we don't want the
harmless ones, so forbidding all of them is not a good solution.

You also wrote:
> if we allowed some kinds of extensions in strict, 
> then what do we call a document that has no extensions?

The question implies that we want to make a distinction. IMHO we don't,
when it's about harmless extensions. Like style properties. Let producers
add tiny private attributes in styles without calling them "not compliant".
But yes, do call "not compliant" a producer that generates <foo:bar><text:p>[....],
that kind of stuff is bound to create trouble in the consumers.

You'll note that style attributes do not create any of the issues you listed
(antivirus scanning, scripts, personally-identifying data, indexing text,
translating etc.). I certainly do agree that all those things are reasons against
"bad" extensions, but since we do have all of these things (scripts, metadata, text)
in the spec already, there's no need to use extensions for those.
The point of extensions is to use them for the stuff that is NOT in the spec :-)

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]