RE: [office] Re: ODF Conformance

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

David,

Thank you for pointing out that there are useful and benign uses of foreign
elements in <style:*-properties> and elsewhere.

I have a question with regard to the two-tiered approach.

If these elements were disallowed at the (strictly-) conformant document
level, would that disturb you so long as they were allowed at the broader
(conformable, in my terms) document level?

Secondly, does it seem practical to you that your products be able to
produce (strictly-) conformant documents that have no such extensions
present?  [I'm not asking for a product commitment, just whether you
consider it to be a reasonable requirement to make squeaky-clean documents.]


Bob,

Where are you expecting the bar to be in this particular case?  Above or
below the addition of style and metadata elements that are not defined in
the ODF specification?

 - Dennis

-----Original Message-----
From: David Faure [mailto:faure@kde.org] 
Sent: Friday, February 06, 2009 02:19
To: robert_weir@us.ibm.com
Cc: office@lists.oasis-open.org
Subject: [office] 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).

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php