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


There is currently a standard (ODF 1.0/1.1) foreign-element-and-attribute
treatment that recommends how a compliant processor could reduce what it
processes to be equivalent to a conformant document (assuming there is one
underneath there) by ignoring the element tags and dealing with the content,
or by ignoring the element completely if there is an attribute that says to
do so (or to not do so).  Those specifications also provide for processing
elements.  The current proposal does not mention processing elements.

In the current draft for 1.2 it is a little more complicated with the
current recommended default behavior depending on whether the element is in
text or not.  (It is not clear why that change is necessary.)

The point is that someone who introduces a foreign element knowing this rule
can be careful to ensure that the foreign-element treatment is benign.

This actually comes up with regard to down-level processing of ODF 1.2
documents by ODF 1.1 documents.  If the ODF 1.2 document uses the new
<text:meta>, a 1.1 processor having the recommended foreign-element behavior
will accomplish the right thing if foreign-element treatment is implemented.
The <text:meta> element, even if it has content, only introduces RDFa
attributes that may be related to that content, but processing the content
as if the <text:meta> tags are not there is exactly the correct thing to do,
taking the content essentially as if it was surrounded by a trivial
<text:span>.  This also works for ODF 1.2 processors that don't support the
in-line RDF markup.  In fact, even if the particular element is supported,
the behavior is still to render the document as if the tags are not there,
apart from however an user is allowed to notice, review and create such
markup.

So there are interoperable situations where foreign-element treatment by the
processor works whether the document is actually conformant but beyond the
capabilities of the processor or extended but beyond the capabilities of the
processor.  I find that an appealing harmony.

By the way, if we go with the single strict schema along with the single
conformant document, the addition of styles and apparently custom
<office:meta> content will be over the line too.  I suppose that doesn't
matter, as long as there is an agreed foreign-element-and-attribute practice
that encourages safe treatment in most cases.

The interesting case for extension by foreign element is, I think, that
however they are introduced (including in a later version of the
specification), it should be done in a way where there is an useful
conformant document remaining after the foreign elements and attributes are
dealt with.  Also, a lot of foreign element introduction could involve
attributes, not only elements, in such a way that there is still an (useful)
conformant document when those attributes are ignored.

So maybe we shouldn't special case this but recommend general principles,
allowing implementers to work it out among each other what ones are useful
for mutual adoption and eventual standardization in some way.  

 - Dennis

PS: The alternative conformance proposals handle these two cases
differently.  The single-level-conformance proposal does not mention foreign
attributes at all, and the dual-level proposal makes breaking changes with
respect to earlier versions of ODF, especially with respect to an attribute
definition (and deprecation), so the recommended default behavior is
different.  As I said, I don't know what the rationale is for the
more-complex and breaking change.

-----Original Message-----
From: David Faure [mailto:faure@kde.org] 
Sent: Tuesday, January 20, 2009 17:05
To: office@lists.oasis-open.org
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:
> 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?

I understand that. But on the other hand, why should an implementation
be marked as "non-conformant" just because it adds one tiny attribute
in a style somewhere for mostly internal reasons?

> 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.

Right, in fact I think that allowing extensions in style properties is a
given,
while indeed allowing any element in the middle of content elements
would just open the door to non-standard content. I think your ideas work
well together: by only allowing extensions inside style properties, only
additional settings to _existing_ content elements can be added, no actual
new content.
Of course styles can affect rendering as well as editing, but that's the
impossible-to-draw line.

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



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