Conformance Clauses Proposal

[robert_weir@us.ibm.com]

I apologize for not reviewing this earlier.  But since I woke up this 
morning at 4am, due to jetlag, I find myself free of meetings for a few 
hours, so I will make some comments now.  Overall I like the progress over 
ODF 1.0/1.1.  This is an important part of the standard, and will get a 
lot of attention during the review in OASIS, as well as in JTC1 when we 
submit ODF 1.2 for PAS approval.  So I'm hoping we can consider my late 
comments and perhaps make another iteration over this section.

I reviewed the "sixth iteration" dated 11/11/2008.

I think it would be good if we started the conformance section with a 
clear statement of what we will be defining.  Something like, "The 
OpenDocument Format standard defines conformance for documents, generators 
and processors, with two conformance classes called loose and strict." 
We'll need something like that for the Scope statement as well.  Probably 
want to synch up on the language.

I'm a little confused by the term "processor", since it is defined, 
somewhat circularly, as "a program that can parse and process OpenDocument 
document".  What is "to process"?  What is intended, beyond parsing? 

To my thinking, we have three kinds of applications:

1) generators (or writers or producers)
2) parsers (or readers or consumers)
3) processors (that both read and write)

I think we may be failing to acknowledge that 3rd kind of program, the 
ones that both read and write.  As we know, this brings in additional 
questions related to round-tripping, and that this is a thorny issue.  But 
it is a legitimate concern, and we should see if there is some language 
the TC can agree to for it, especially considering that most ODF 
applications fit into that category, and in practice interoperability 
would be enhanced by any firmer guidance ODF 1.2 can provide in this area.

Here are some specific comments:

Document processing -- 

"Documents that loosely conform to the OpenDocument specification..."

We introduce here the term "loosely conform" but we don't clearly indicate 
what our conformance classes are.  For example, do we want "loose 
conformance" and "strict conformance"?  or plain "conformance"?  Is there 
a better word than "loose"?  It carries a negative connotation in my ears. 
 

Also, do we need loose conformance at all?  Why not just have a single 
conformance class and anything beyond that is not conformant?  Then, if 
there occurs a commonly-used set of extensions to ODF, in a foreign 
namespace, then we can either included that in ODF-Next, or (more simply) 
define a profile for the extensions.

"Foreign elements and attributes shall not be part of a namespace that is 
defined within this specification."

"part of a namespace" is rather loose.  The term used by the Namespaces in 
XML Recommendation is "associate".  So I suggest, "Foreign elements and 
attributes shall not be associated with a namespace that is defined within 
this specification."

"If a foreign element has a  or  ancestor element and is a child elements 
of an element which may include..."   Typo.  Should be "child element" 
(singular).  Or do we really mean "descendant element"?

"For foreign elements that occur at other locations, conforming processors 
should not process the element's content, but may only preserve its 
content"

We have not defined "process".   Does it include "preserve its content"?

Also, why not make preservation of content of foreign elements be a 
"should"? Is there any reason why we would not make that recommendation?

In any case this "Document processing" section seems misplaced.  I wonder 
if it fits better if put in the Generator or Processor conformance 
section, since it is defining conformance.

So overall, I find this document processing area thorny and troublesome. I 
would not be disappointed if it were entirely removed from the standard, 
or moved to an informative annex on "How to extend ODF".  There is little 
value to implementors or users in having a conformance class for documents 
that are extended in nearly-arbitrary ways.  Nothing written here really 
allows such extended documents to interoperate.  On the one hand, I don't 
believe that there is anything intrinsically evil with extensions, but I 
don't think that we need to favor them with the label "loose conformance". 
 

Do we know what implementations today use foreign elements and attributes 
according to this section?  Is the usage widespread?

"Conforming OpenDocument Documents" -- this is defined currently as a 
condition, if/then.  But I think it should be stated as a requirement: "A 
conforming OpenDocument document shall adhere to the specification 
described in this document...".  Similarly, "An OpenDocument document 
which is also an OpenDocument Package shall...". 

Generally, we should use "conform" rather than "adhere" whenever possible.

Do we want to require a specific XML character encoding? 


2.1.3 -- "f the XML root is.... then it  shall be valid with respect to 
the strict schema defined by this specification."  What is "it"?  "XML 
root" doesn't make sense?   "Sub document" maybe?  A similar question in 
2.1.4.

"Conforming OpenDocument Generators" has the first conformance requirement 
stated as "It shall not  create any non-conforming OpenDocument document 
of any kind."  But this, stated as a negative, is untestable.  How can an 
implementation prove that it is incapable of producing a non-conforming 
ODF document?  What, for example, if the power goes out when in the middle 
of saving a document?  Would that render the entire application 
non-conforming?

I'd state this requirement more simply (and more testable) as "It shall 
produce documents which conform to this standard".


We might factor out the common requirements between normal and loose 
conformance rather than repeating material.  For example, we are currently 
stating the documentation requirement twice.

My preference would be to make the document requirement be a "shall" 
rather than a "should".  I think we're giving implementors a lot of rope 
to play with by allowing a loose conformance class, a significant ability 
to extend the standard in incompatible and proprietary way.  As stated 
before, I'd be happy if this ability were removed altogether.  But if we 
do allow it the label of "conforming" than I think we should require 
documentation of the extensions, not merely recommend it.

"Conforming OpenDocument Processors" -- "process" is not defined.
"It  be able to parse and process OpenDocument documents of one or more of 
the defined document types (defined by their MIME types) any of which are 
represented in packages."   I don't think we need to mention MIME types 
here.  We can just say "able to parse and process OpenDocument packages of 
one or more of the document types defined by this standard".  Better even 
if we can give a section reference.
Why is the single XML version a "may" rather than at least a "should"?  It 
is odd to have the single file version be present (and not deprecated) if 
we do not feel it warrants more than a "may" for support.

Regards,

-Rob