Re: [office] Conformance, Specification Quality and OASIS Recommendations

[robert_weir@us.ibm.com]

Michael.Brauer@Sun.COM wrote on 03/02/2009 11:25:46 AM:

> 
> > 
> > 6) 1.4.2.1 is either circular or insufficiently defined  We have now 
"A 
> > conforming OpenDocument document shall adhere to the specification 
> > described in this document...".  But what does it mean to "adhere"? If 

> > this is the same as to conform, then this is circular.  If it means 
> > something else, then it is undefined.  So the question is:  Did we 
mean to 
> > require something here?  If so, what?
> 
> SVG uses a similar phrase:
> 
> http://www.w3.org/TR/SVG11/conform.html#ConformingSVGDocuments
> 
> My reading of this is that a conforming document must not only meet the
> requirements we state in the conformance section, but all we state in
> the specification document, unless they are marked informative. Maybe it
> is not required to explicitly state that. Maybe native English speakers
> find a better phrase for this.
> 

I look at it like this.  We have normative statements scattered throughout 
the text.  When we convert many of the must's into shall's we will have 
even more.  However, the vast majority of them make no reference to a 
conformance target or a conformance clause.   So if we say, deep in the 
description of an element we state a requirement, if it is not somehow 
connected to a conformance target and class, it is essentially a broken 
reference.  We state "shall" but not what conformance requires it.

Perhaps it would be useful to review a few examples of what these 
additional constraints are for conformant documents.  We already require 
validity to the schema and conformance to the packaging specification. Are 
there hundreds of additional requirements for documents, or just a 
handful?  We have requirements on referential integrity between styles.xml 
and content.xml.  We might call that out explicitly. 


> > 8) I'm not sure I like "conforming" to be part of the name of a 
> > conformance target or conformance class.  If the conformance target is 

> > called "conforming extended opendocument document" then what do you 
call 
> > it when such a document does not conform?  For example, it has an 
error in 
> > the core part of the schema and is not valid.  Is it then a 
"nonconforming 
> > conforming extended opendocument document"? So I would not have 
> > "conforming" be part of the name of any conformance target or class.
> 
> Would removing the italic formatting from the term "conforming" be
> sufficient to address this concern?
> 

That would be good.


> > 
> > 12) 1.4.4 "parse and interpret" -- I'd like to see if we can make a 
more 
> > testable requirement here.  It may not be possible, since a Consumer 
> > ranges from a full text editor down to possibly a Zip program or an 
XML 
> > parser.  Our practical problem is that we have not defined a minimal 
set 
> > of elements which a Consumer must understand.   In the general case, 
this 
> > is probably right.  But we might consider also defining conformance 
> > targets according to Appendix D.  So define an "ODF Text Consumer", 
"ODF 
> > Spreadsheet Consumer", etc. and require interpretation of 
corresponding 
> > ODF features.   I think this would be a tremendous gain for 
> > interoperability.
> 
> I agree that this may make sense.
> 

I think we should at least define:

ODF Text Document
ODF Spreadsheet Document
ODF Presentation Document

and

ODF Text Document Producer
ODF Spreadsheet Document Producer
ODF Presentation Document Producer

and

ODF Text Document Consumer
ODF Spreadsheet Document Consumer
ODF Presentation Document Consumer

Requirements would be:

1) Be a conforming ODF document, consumer or producer, AND
2) Use the correct registered mime-types according to Appendix C (which 
would then become normative) AND
3) Process features corresponding to the declared mime-type according to 
Appendix D (which would then become normative).

Note that this would not change the conformance status of any existing 
application or document.  So if an existing application, for example, does 
not support "filters", then it could still be a conforming ODF Consumer, 
but it would not be a conforming ODF Spreadsheet Document Consumer.  In 
other words, this would introduce additional conformance targets with a 
"higher floor".

-Rob