Moving forward on Conformance

[robert_weir@us.ibm.com]

It might help to take a top down approach to defining the conformance 
clause, and see whether we agree on the broad strokes at least.  We might 
not be able to avoid a vote on the details, but let's see what we agree 
first.

A conformance clause can define conformance for one or more "products". A 
product is the subject of conformance, the thing that conformance is 
defined for.  In the case of markup languages, it is typical to define the 
document itself as a product, as well as one or more applications that 
operate on that document.

ODF 1.0 & ODF 1.1's conformance clause was not as crisp as I'd like it to 
be, but if you parse out section 1.5 carefully, you'll see that it defines 
conformance for:

-- Document
-- Applications 
-- Applications that read and write 

You can gleam a bit more by reading the entire standard, but if you look 
at just the conformance clause you get those three products.

A standard can also define one or more conformance "classes" for each 
product.  In the case of ODF 1.0/1.1 there is only a single conformance 
class, the unnamed default conformance class.

So the question for us in ODF 1.2 is to determine what conformance 
products and classes we want to define.  If our intent is to confuse 
adopters of ODF, we could easily define a large matrix of a 48 or more 
different product/class combinations, such as "ODF Spreadsheet Consumer of 
the Loose Legacy Class".   But my personal belief is when the number of 
conformance classes starts to exceed the number of implementations of the 
standard, then we're up to no good.

So let me propose a set of possible product combinations and see if there 
is generally agreement on which ones we use:

A) Document/Applications/Applications that read & write (same products as 
ODF 1.1)

B) Document/Producer/Consumer (What Michael has in his latest draft)

C) Document/Producer/Consumer/Processor (adding processor, which we could 
define as an application that both reads and writes and for which we could 
additionally make statements about "preservation" or "round-tripping" if 
there is consensus to do that)

D) Document/Spreadsheet Document/WordProcessor Document/Presentation 
Document...Spreadsheet Consumer, WordProcessor Consumer...

Choice D) would be like B), but we explicitly define products for 
individual document types and applications that operate on those document 
types.  Probably not worth it unless we can say state different 
requirements for each document type.  But it is possible, for example, we 
can say that an ODF Spreadsheet has <office:spreadsheet> as the root and 
uses OpenFormula for the value of the table:formula attribute, etc.  We 
could also make Appendix D normative for the individual document classes.


So, is there any consensus on what we want as products in the conformance 
clause?   B) or C) are fine for me.  I'd like to see us get to D) over 
time.  A) is out for me, because the ODF 1.0/1.1 definitions are not 
particular crisp and easy to parse.  Whatever we do we need to improve on 
what we had then.

If we can get some agreement on the products, then we can talk about 
whether we want multiple conformance classes on top of that. 

The strict/loose distinction has been made in other standards, but that is 
more typically done where legacy documents could only fit into only the 
loose class.  But I have not heard anyone claim widespread use of 
arbitrary private extensions in ODF 1.0/ODF 1.1 applications.  So whatever 
we decide, we should be concerning ourselves with real documents and real 
applications, not merely theoretical ones.  The fact that ODF 1.0 allowed 
arbitrary extensions does not oblige us to preserve this capability as 
conformant if in fact this feature was never or only rarely used.  We 
should just count ourselves lucky and move on.  On the other hand, any 
widespread conformant constructs from ODF 1.0/1.1 should be respected, I 
believe.

So I think the choices we have are:

A) Single conformance class, same definition as ODF 1.0/1,1, but cleaned 
up to meet OASIS requirements

B) Single conformance class, but stricter than ODF 1.0/1.1, i.e., allow 
extensions in particular places but no the general use of foreign 
elements/attributes. (So, essentially what Michael has in his latest 
draft).

C) Single conformance class that is even stricter than B) not allowing any 
extensions.  Some real documents that were conformant to ODF 1.0/1.1 would 
not be conformant under this definition.  (This is what I proposed 
earlier).

D) Dual conformance classes, say loose and strict, where loose=A and 
strict = B

E) Dual conformance classes, say loose and strict, where loose=B and 
strict = C

F) Dual conformance classes, say loose and strict, where loose=A and 
strict = C


And finally we need to decide whether we apply the conformance class(es) 
to documents only or make some statement about other products, such as 
Consumers/Producers.  The main question seems to be whether a conformant 
Producer is required to produce a non-extended document. 

I think the choices are:

A) With a single document conformance class, we have a single class of 
Producers/Consumers.  Producers produce conformant documents, Consumers 
consume conformant documents.  We can make some additional statement about 
how to process non-conformant documents.

B) With two document conformance classes we have a single conformance 
class for Producers/Consumers and require that they are able to 
produce/consume strict documents, but may also produce/consume loose 
documents.

C) With two document conformance classes we have a single conformance 
class for Producers/Consumers and require that they are able to 
produce/consume loose documents.  In other words, there is no requirement 
that a conformant producer/consumer be able to handle strict documents.

D) With two document conformance classes we have a two conformance classes 
for Producers/Consumers, loose and strict, and each is required to be able 
to read and write documents of their class.   Obviously the loose 
applications become an interoperability black hole, since they are 
extended in ways that the standard can not speak to, other than to make 
statements about how to ignore or report things that the consumer does not 
understand.

My preferences are as follows:

1) For products, I'd like to see us follow C) and define conformance for 
ODF Documents, Producers, Consumers and Processors.  B) would also be 
acceptable.

2) For conformance classes, My preference is for C, but B would also be 
acceptable.  Of the dual-class choices, E is the least offensive.

3) And for the last question, this will depend on what agreement we can 
arrive to on the other two questions, but I generally want to avoid a 
proliferation of conformance classes, with applications as well as 
documents.