Confirmation Flavors: #1-#2 - Nowhere-Implemented and Unimplemented

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

Along with sorting out the difference between confirmation cases and test cases, test suites, and kinds of test, I have been collecting some known cases that appear to be quite different from each other.  Rather than develop and document the cases I have, I thought I'd summarize their basic characteristics first.

I am not sure which ones of these flavors are meaningfully in-scope, but I think it is useful to know what they are and find out what variations others have encountered.  Also, there is nothing about priorities for coverage here, because I think that depends on our review and identification of interoperability pain points.

In any case, here's the first flavors I ran into recently.

 - - - - - - - - - - - - - - - - -

#1 NOWHERE-IMPLEMENTED FEATURE

As part of Errata work on the ODF TC, it became important to assess whether style:wrap-dynamic-threshold (or its misspelling, style:wrap-dynamic-treshold) had been implemented anywhere (see ODF 1.0 section 15.27.22).

It became clear that there appeared to be no implementations of this feature in any ODF implementation, including for ODF 1.1.  This was accomplished by surveying implementers and also making a small test where the attribute was injected into a document and its impact observed.

The typical situation was that (1) the presence of the attribute had no effect, (2) there appeared to be no User Interface provision for noticing it and adjusting it, and (3) a Save As would eliminate the attribute in the new copy of the document.  This all happened silently.

Note that this would not be a high-visibility interoperability case because there are apparently no implementations at this point.  But the behavior raises questions about unimplemented features generally.

#2 UNIMPLEMENTED FEATURE

The ODF specifications do not mandate processing for all features of any of the ODF document types (and some document types are not specified with any amount of detail -- templates and master documents come to mind).

Although there are conformance requirements with regard to the handling of foreign elements that use non-ODF namespaces in the XML, there is not much guidance on what the expected behavior is when an ODF-specified feature occurs in a document and it is not supported in rendering and processing/manipulation by a particular ODF-conformant software package.  There is a requirement to accept documents that are schema-valid but no requirement that all features be supported.

There is also no guidance on what should be done with the markup that invokes unsupported features when a document is saved from that particular processor, whether or not the elements that exercised the unsupported features were touched during processing.

These might or might not be cases that are identified as a high-priority for interoperability and supporting guidance.  Having agreement on the failure mode might be more important as a first-order concern.

It would be very useful for software packages that are offered for use in interoperability settings to be accompanied by some sort of declaration about how unimplemented features are handled, even on a case-by-case basis.  I can see ways to inspect for that support and have suggestions about the observed and the desirable behavior when the features is not supported.

 - - - - - - - - - - - - - - - - - -



 - 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