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

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

I favor your suggestions.  Definitely +1.

I have two observations.  

8. Non-conforming ODF Documents (under topic 8).  

   8.1 I don't think there is any such thing as a "non-conforming ... ODF
Document."  An artifact that does not satisfy one of the conformance targets
for an ODF Document is not (a representation of) an ODF Document (of that
class).  

   8.2 Some artifacts may be just a little-bit non-pregnant with ODF
goodness, but I don't think we need to worry about that, tolerance for bugs,
etc.  It is a practical matter, but I know of no meaningful way to define a
near-ODF Document.

   8.3 To the extent that it is arguable whether or not an artifact does or
does not satisfy one of the conformance targets, we have work to do.  

   8.4 We might also provide some guidance on what a conforming processor
might do to attempt to find the pony in an artifact that fails to satisfy a
conformance target but can somehow be construed as an ODF Document
representation, just as we have (loose) guidance on construing an extended
ODF Document as a (mumble) conformant ODF Document.  

   8.5 As a matter of practice, I think we should not speak of thingies that
fail to satisfy a conformance target as ODF documents of any flavor.  (There
are philosophical objections to speaking this way too, but we don't need to
go down that road.)

12. Document Types and Higher Floors (under topic 12).

   12.1 I am completely aligned with the need to identify the different
document types that we propose to recognize in a normative way, and
connecting the dots around MIME types, <office:body> content, and other
interdependencies as you suggest strikes me as the way to do it.

   12.2 I am a little nervous about Appendix D only because it is a rather
casual identification of features.  I think my nervousness will be abated if
we carry out the tightening of normative language and conformance targets
suggested in your commentary on (topic 6).  I don't know if nailing this
down works as a 1.2 requirement (being nervous about our process capability
and level of effort), but I have no objection to it being considered as an
objective.

 - Dennis

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
http://lists.oasis-open.org/archives/office/200903/msg00028.html
Sent: Saturday, March 07, 2009 16:59
To: office@lists.oasis-open.org
Subject: Re: [office] Conformance, Specification Quality and OASIS
Recommendations

Michael.Brauer@Sun.COM wrote on 03/02/2009 11:25:46 AM:
http://lists.oasis-open.org/archives/office/200903/msg00014.html

http://lists.oasis-open.org/archives/office/200903/msg00002.html
> > 6) 1.4.2.1 is either circular or insufficiently defined  We have now 
[ ... ]
> 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

[ ... ]