ODF Extensibility and the Foreign-Element Fall-back mechanism
Dennis E. Hamilton
dennis.hamilton at acm.org
Fri May 28 05:37:27 CEST 2010
Following the 2010-05-26 Teleconference discussion of ODF Extensibility, I
wrote down some of my thoughts on how it is difficult to introduce
extensions, such as using MCE as a foreign element that carries further
extension material, when the consumer does not recognize the extension (or
the MCE mechanism). After the teleconference, I posted a simple statement
of my concerns over foreign-element rules on the ODF TC list. That note is
forwarded at the bottom of this message.
Fundamentally, there is no required consumer behavior for the treatment of
foreign elements encountered in an ODF document. In addition, when the
foreign element occurs as part of mixed content, the *recommended* behavior
is to strip the start and end tags of the foreign element and leave anything
else in place to be consumed as part of the mixed content where the foreign
element occurred. (I am oversimplifying although it would be great if it
were nearly that simple. It is essentially this flattening that I point out
is incompletely specified in item (1) in the forwarded note, below. It is
also not stated in ODF 1.2 whether this flattening can continue recursively
on what may now be seen as foreign elements in the just-flattened mixed
Another problem has to do with a principle that applies generally in ODF
pretty much. Basically, the only time an element body can have PCDATA is
when that PCDATA is textual content of the document. The idea is that, if
all you wanted to do is extract the narrative text from a document in the
sequence in which it occurs, all one needs to do is strip all of the element
tags. This doesn't work 100%, but that is the essential idea. (The
exceptions include hidden text, annotations, and removed material that is
held as part of change-tracking.)
Here is where there is a problem with MCE Alternative Content. If the
occurrence is as an element in mixed content, and the
<mce:AlternativeContent> element is flattened, all of the choices and any
fallback will be flattened with it, and their flattening will likely lead to
an undesirable result in any resulting mixed content.
There is one mitigation (and it is different between ODF 1.0/1.1 and ODF
1.2). In ODF 1.2, the office:process-content element (being deprecated in
1.2!) could be present and set false on all of the <mce:Choice> elements to
*recommend* (sorry) to a consumers that the <mce:Choice> element not be
interpreted. Then the <mce:Fallback> element could determine the result
(including by its absence) in the case MCE is itself not understood by the
To accomplish the same sort of thing with an ODF 1.1 document, there are
different rules for when flattening happens and the definition for
office:process-content (and the default in its absence) differs.
I am sure that I missed some cases and could have simplified this
explanation more, but this is what I understand about ODF 1.2 extensibility
at this point.
From: Dennis E. Hamilton [mailto:dennis.hamilton at acm.org]
Sent: Wednesday, May 26, 2010 07:03
To: 'Michael.Brauer at Sun.COM'
Cc: ODF TC List (office at lists.oasis-open.org)
Subject: Concerns for the Foreign-Element Fall-back
Michael, here is more on my concerns about the foreign-element handling in
ODF 1.x and needing the fall-back to be predictable by producers who want to
be careful that consumers will achieve a reasonable result:
1. The substitution process is incompletely-specified. I.e., if a foreign
element has namespace bindings and use of XML-defined attributes (xml:lang,
xml:space, xml:id, RDFa attributes, etc.), those need to be absorbed somehow
if the tags are simply dropped and the body retained as part of the text.
(I was thinking that a substitution with <text:span> Might be preferable
because of this. Also, being in a place where <text:span> is allowed would
be a good place to specify where this form of rewriting should be done. If
<text:span> is not allowed where the foreign element occurs, then leaving
the body should not be provided for.
2. The use of SHOULD in ODF 1.1 and ODF 1.2 is as "recommended." There is
no requirement that it be implementation-defined or that there must be
justification over doing anything else. (That is in the IETF RFC, but not
the JTC1 definition of the provision.
3. Considerations for preservation of foreign elements/attributes that are
not understood/supported seems to be problematic.
4. There is no consideration for how all of this fits in with change
tracking and RDF markup.
- - - - - - - - - - - - -
Standards are arbitrary solutions to recurring problems (R. W. Bemer)
Although not by becoming the recurring problem (orcmid).
When you find yourself in a hole, stop digging.
More information about the sc34wg6