Confirmation Flavor: #3 Incorrectly-Generated ODF

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

Here's a case that it is hard to imagine creating a test for.

#3 INCORRECTLY-GENERATED ODF 

Under certain conditions, processor X produces an ODF 1.1 .odt file where the content.xml and styles.xml documents are valid according to the schema, but a constraint stated in the specification is violated.  

Processor Y fails to load the document, reporting an error in the content.xml file.

Processor Z loads the document and processes it as correct.  When the document is saved, the resulting content.xml does not violate the constraint of the specification.

Because this is a negative condition (the specification is violated), there is no specified behavior for it in the ODF specification.  The document is, technically, not conforming in any respect.

On the other hand, one might consider that Processor Z behavior is superior to Processor Y's.

At the same time, it is very difficult to know how this would show up as a confirmation case in the work of the OIC TC.  For one thing, the case would only come to light if someone had a rather stringent checker for validity of ODF documents, and the apparently-erroneous case was encountered in an actual document (typically as the result of an interchange failure).  These are situational and may likely always be more about incident reports on an implementation than what OIC TC would have in any compilation of cases in support of interoperability.

Guidance about graceful behavior might be valuable, and implementations that silently accept the aberrations might document their processor behavior somewhere.  

Note that a future revision of ODF might relax the restriction or it might preserve the constraint.

 - Dennis

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