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.