[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Conformance, Specification Quality and OASIS Recommendations
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 [ ... ]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]