OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Conformance Clause(s) should be clearly identified as such in Part 1,2,3


From Jacques Durand (TAB member):
 
[0] General Comment:
 
Overall the specification appears well structured, and quite well and carefully written. I wish the split into 3 parts was better explained however: I only have a clue of the existence of the "other" parts by reading the "related work" in the front page. Maybe the Introduction of Part 1 (section 1.1) could be more specific as what role Part 1 is playing in the complete specification, and briefly mention Part 2 and 3 and their relationship to Part 1.
 
 
[1] Missing a formal "Conformance Clause" section in Part 1, + a better introduction of conformance targets.
 
As I started to review the specification, it appeared at first that a Conformance Clause(s) is missing
http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html
 
Appendix G1 in Part 1 suggests that there should be several ("New conformance clauses and labels").
 
After a closer look, it appears that section 2 plays this role but without ever stating it clearly. So it is not obvious to the reader that Section 2 should be interpreted as the confformance clause section, defining the conditions to be met by implementations to formally claim conformance.
 
One option is to retitle Section 2 as the Conformance Clauses section, and in addition to provide a better (even if informal) definition of the conformance targets inside, independently from their conformance requirements. 
 
For example, currently Section 2.1.1 starts right away with "An OPenDocument document shall meet the following reqs..." without even telling me what is (even roughly) an OpenDocument document.
And it keeps going right away by telling me "if it is a package, then..." and here again I don't know what is a package (only really defined in Part 3?)
 
Another approach is to keep Section 2 title as is, but modify content so that it only introduces and describes informally the various implementation types / conformance targets ( documents, consumers, producers ...)
Then add at the end of the specification a Conformance Clauses section, that will contain most of the current content of section 2 (conformance conditions for each conformance target).
 
Note that if Part 3 contains in turn a conformance clause for "packages", this clause should be referred by Part 1 clauses.
 
 
[2] Missing a formal "Conformance Clause" section in Part 2.
 
Same remarks as in [1], about Section 2 that should become the formal conf clause section.
Also again, the reader has no clue as to what is - even informally - the rationale for these various conformance targets: Small / Medium / Large group evaluators. These should be defined or at least briefly introduced separately from their conformance requirements.
 
 
[3] Missing a formal "Conformance Clause" section in Part 3.
 
Same remarks as in [1], about Section 2 that should become the formal conf clause section.
Also as a reader I'd love to see an informal definition of what a "Package" is, what's the intent, and what is the rationale for package vs. extended package, independently from the detailed conformance requirements for these.
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]