Re: [office] ODF 1.2 Single-Level Conformance and Law of UnintendedConsequences

[robert_weir@us.ibm.com]

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 01/19/2009 
11:44:34 AM:

> 
> That was a very interesting discussion on conformance with regard to
> having a single-level conformant document.
> 
> I want to reaffirm that, with the single-level approach, we need to 
> deal with all of those places where implementation-defined features 
> are allowed.  (Another example is in the use of alternative 
> renditions and objects where there is currently no specification of 
> MIME types for recognized ones.)
> 

The TC may certainly address other areas where ODF currently has 
implementation-defined features, but I wouldn't say this is a necessity. 
Remember, the proposal for "loosely conformant" documents dealt with only 
a single dimension of extensibility, that done by the allowance of foreign 
elements and attributes.  If we do not allow such extensions in conformant 
ODF 1.2 documents, then the status quo with regards to other 
implementation-defined behaviors remains unchanged unless the TC wishes to 
address those areas separately.

> What I think is more interesting is that having only strictly 
> conforming 1.2 documents may have the unintended consequence of 
> prolonging the life of ODF 1.1 processors and ODF 1.1 documents. 
> The major ODF 1.2 addition, OpenFormula, is perfectly admissible for
> usage as a 1.1 table:formula value once that part of the ODF 1.2 
> specification is stable and available as an OASIS Standard.  It 
> hadn't occured to me until now that there might be an useful 
> transition via ODF 1.0/1.1 with extensions from 1.2 (among others) 
> rather than ODF 1.2 wholesale.  And the prospects for successful 
> ingestion of 1.2 and interchange with implementations of 1.2 
> processors would remain pretty good.  Hmm. ...
> 

I don't follow that argument.  Since current implementations do not (to my 
knowledge) introduce foreign attributes and elements into documents, they 
would not be impacted by this change.  Every conformant ODF 1.1 document 
produced by OpenOffice, Symphony, MS Office with Plugin, etc., should also 
be a conformant ODF 1.2 document under the proposed change (if the 
document updates its office:version attribute).

> My conservatism around preference for the dual levels has to do with
> not wanting to eliminate something valuable by mistake. 
> 

If it was valuable, then I'd expect to see some implementation, any 
implementation, use the feature in the 4 years since ODF 1.0 was approved. 
 But it hasn't happened.  Of course, is someone finds it to be valuable, 
they can still extend their documents.  It simply won't be conformant. The 
standard can't tell anyone what they can and cannot do.  That's not our 
role.  What we do is define conformance as a basis for interoperability. 
Arbitrary extensions are outside of any basis for interoperability, so I'd 
argue they should be outside of conformance.

> (And, of course, having a strictly conformant document is no 
> assurance of interoperability, since a conformant processor, as 
> defined so far, need not provide for the semantics of all features 
> and there are many places of underspecification which remain to be 
> dealt with).  I am all in favor of stricter specification, but not 
> so confident about having *only* (strictly-) conforming documents.
> 

True, but there are differences between errors and omissions that can be 
fixed and innate design flaws.  The current extensibility mechanism is a 
design flaw in ODF, IMHO.  We've been lucky so far that no one has used 
it.  In the end, I want conformance defined by what _this TC_ says, not by 
what any random implementer decides to do by way of extensions.   We'll 
need to tighten the standard up in a number of areas to make this happen.


>  - Dennis
> 
> PS: I am distressed to hear the casual supposition that the RDF 
> metadata can be used to introduce behaviors into a document and its 
> processing and that it can be used to handle extension cases.  It is
> called metadata, not processing instructions, for a reason.  It 
> might be able to express implementation assumptions or required 
> capabilities (I need a million rows in this table, sort of thing), 
> but there is nothing in the specification that would have a 
> processor attend to the metadata as instructive and there are no 
> agreements on how such concepts would be expressed, any more than 
> with custom metadata.xml entries.  Using RDF for semantic markup 
> (so-called) is very different than extension via elements and 
> attributes and rules for handling unrecognized ones.
> 

The point is that the ODF 1.2 metadata was designed to remove the need for 
foreign elements and attributes. That original extensibility feature was 
not intended for extending the processing model of ODF, though in theory 
it could be (mis)used for that purpose.  But in practice, the mechanism 
has not been used at all.