RE: [office] Concerns for the Foreign-Element Fall-back

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

In reporting on this topic back on the SC34 WG6 list, I provided more
analysis about the flattening procedure that is used when a foreign element
appears in mixed-content (along with other conditions related to <text:h>
and <text:p> ancestry).  I am including the additional text here for the
record and to further the discussion.

I also note, in passing, that when a foreign element is flattened because it
is not recognized by a consumer, there is no way for the consumer to
determine whether the foreign element has mixed content or not, and
therefore the interpretation of white space in the spliced-in flattened
material is unclear.  There might be actions that the foreign-element
producer could take to assist in that being handled properly (perhaps by
using xml:space).

The more I look at the complexity of this, the more it looks to me as if,
instead of stripping the foreign-element tags, they might be replaced with
<text:span> tags and perhaps <meta:span> if needed.  This would be in order
to preserve RDF dependencies, xml:id, and namespace declarations (with
appropriate precautions in case the binding for the text namespace is
changed in the foreign-element tag).

I haven't looked more closely at the impact that either flattening or
spanning have on the occurrence of <text:change*> elements in the content of
the foreign element.

 - Dennis

-----Original Message-----
From: sc34wg6-bounces@vse.cz [mailto:sc34wg6-bounces@vse.cz] On Behalf Of
Dennis E. Hamilton
<http://mailman.vse.cz/pipermail/sc34wg6/2010-May/000098.html>
Sent: Thursday, May 27, 2010 20:37
To: SC 34 WG 6 mailing list
Cc: Michael Brauer
Subject: ODF Extensibility and the Foreign-Element Fall-back mechanism

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

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

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.

 - Dennis

 

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
<http://lists.oasis-open.org/archives/office/201005/msg00356.html>
Sent: Wednesday, May 26, 2010 07:03
To: 'Michael.Brauer@Sun.COM'
Cc: ODF TC List (office@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.


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







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