RE: Foreign elements and attributes

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

Hi Rick,

I take it that your suggestion is to redefine extended documents to only
recognize foreign attributes (and foreign attribute values?).
Foreign-element tolerance and rules for dealing with unsupported/unknown
foreign elements (including the special process-content attribute) would no
longer be included in the ODF specification.

I find that to be an interesting simplification, especially with regard to
the ease with which foreign attributes can be ignored.  There is an
appealing tidiness to this case.

This does not deal with the upward compatibility from ODF 1.1 that is
promised for ODF 1.2 according to a statement I just came across, and I have
a few reservations about its adequacy, as opposed to its appeal. 

The following remarks are all speculative, because we don't know whether
anyone will stub their toe on these or not.

 - Dennis
 
DISCLAIMER: This message provides my personal observations as a participant
in the ODF TC and an interested party in the development of open standards
for electronic documents and their processing.  Any similarity to an
official position of the ODF TC or of OASIS is purely coincidental.  Were
there such an official position, there'd be provision of a link to the
official minutes or other approved document where an official position is
expressed.

Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability 
mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 

ANALYSIS
========

1. We still have a problem with foreign attribute values on existing
attributes.  When such an attribute has no default value (the defined
fall-back) and the attribute is required, the document would be
unacceptable.  I don't think your proposal addresses this case anyhow, but I
do notice that language being introduced for it has this hole.  I also note
that those places, such as table:formula, where all of the values are
foreign in ODF 1.1 [and presumably still permitted in ODF 1.2 (extended)
documents], the fallback from only one something to only nothing is pretty
stark.

2. One problem with the use of attributes only is that there can only be one
occurrence of an attribute of the same name per element.  There is no
provision for multiplicity, repetition, etc.

3. One way to deal with situations like (2) is to use the ODF counterparts
of <div> and <span> or (hack, cough) the ODF bookmark provisions that allow
hierarchy to be transcended in the manner exploited by the RDF Metadata
feature.  These are, unfortunately, narrowly-defined and constrained for ODF
in such a way that they do not provide a general solution.  This is also an
awkward solution where the introduction of an element structure would simply
do the job.

4. I said this is all speculative, because we don't know whose situation
would be thwarted by the constriction.  That is what motivated me to support
the dual levels, one that is upward compatible from 1.1 and one that
provides a level of Ivory Snow ODF that some parties wish to be able to
require for procurement and regulatory purposes.  I'd rather not mess with
upward compatibility until there has been adequate notice accompanied by
provision of clearly-adequate alternative provisions.  

[PS: "Ivory snowness" is a reference to long-past soap-opera advertising of
Ivory brand products as "99 and 44/100 percent pure."  No, I don't know what
sort of earmark the remaining 56/100 % was either and I don't know how
reassured we had any right to feel.]


-----Original Message-----
From: Rick Jelliffe [mailto:rjelliffe@allette.com.au] 
http://lists.oasis-open.org/archives/office-comment/200903/msg00055.html
http://lists.oasis-open.org/archives/office-comment/200903/msg00056.html
http://lists.oasis-open.org/archives/office-comment/200903/msg00057.html
Sent: Monday, March 02, 2009 21:26
To: office-comment@lists.oasis-open.org
Subject: Re: [office-comment] Foreign elements and attributes

May I suggest that there is an alternative to the current draft that 
would satisfy more stakeholders and be less work?

It is to ban foreign elements, but allow foreign attributes, with only a 
single conformance class.

This seems to me to meet the following objectives:

[ ... ]