- From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
- Date: Thu, 16 Jan 2003 17:58:37 -0500
- To: "David Marston/Cambridge/IBM" <david_marston@us.ibm.com>, www-qa-wg@w3.org
David I agree with Mark. I think you are reading way to much into strict conformance. All it is, is another way of saying extensions are not allowed. Strict conformance does not prevent a spec from having levels (modules, profiles or choices) as long as it defining (describing) them or explicitly states that you can have levels, modules, etc. lynne At 04:55 PM 1/16/2003 -0500, Mark Skall wrote: >At 04:21 PM 1/16/2003 -0500, David Marston/Cambridge/IBM wrote: > > > > > >>The major dilemma we had was as follows: >>A product could vary along some Dimensions of Variability, notably >>discretionary choices, but not implement any extensions. Is this >>"strict conformance"? > > >This is still "strict conformance." The term "conformance" has to do with >implementing features exactly as allowed in the spec/rec. Thus, >implementing the DOVs not having to do with extensions does not violate >"strict conformance." I think our original definition of "strict >conformance" bears this out. > >>Lynne proposes: >> >8. Insert the following as the 3rd paragraph in Guideline 9 >> >Disallowing extensions for any part of the specification is called strict >> >conformance. [te paragraph from G3] Strict conformance is defined as >> >conformance of an implementation that employs only the requirements and/or >> >functionality defined in the specification and no more (e.g., no >> >extensions to the specification are implemented). No discretion is >> >granted to implementers, and any requirements for handling deprecated >> >features must be followed. >> >>As a way to confirm your intent, I deduce that the "strict conformance" >>definition in GL 9 actually relates to several DoV as enumerated below. >>Strict Conformance means *all* of the following are true: >>(GL 6) there are no levels (unclear) >>(GL 7) no variation is allowed in treatment of deprecated features >>(GL 8) no discretionary items exist in the spec >>(GL 9) no extensions are allowed > > >I don't think that was Lynne's intent and I certainly would disagree with >this. > >>On the other hand, the strict conformance policy can apply only to some >>of the product classes (GL 2), some profiles (GL 4), or some modules >>(GL 5). If true, this validates the numerical order of the guidelines >>going from general to specific. (It still would if GL 6 "crossed the >>line" and Strict Conformance applied on a per-level basis.) >> >>I would like the wording to be explicit about profiles, modules, and >>levels. I think that Strict Conformance should mean that there are no >>levels, as part of the goal to make it a useful term. > > >Again, I strongly disagree. That would re-define the definition of >"strict conformance." > >>Notice that the interaction between the definition and deprecation is >>slightly different than the others. Deprecation is compatible with >>Strict Conformance, as long as you don't have discretionary choices (GL 8) >>regarding the deprecated features. Fine point: if all implementations >>must consume deprecated content and treat it in some specified way (e.g., >>must ignore it), does the discretionary choice of whether to warn the >>user about deprecated input violate Strict Conformance? If so, we are >>being really strict, because issuance of warnings might be a minor >>secondary effect to most (but not all) implementors. >>.................David Marston > >**************************************************************** >Mark Skall >Chief, Software Diagnostics and Conformance Testing Division >Information Technology Laboratory >National Institute of Standards and Technology (NIST) >100 Bureau Drive, Stop 8970 >Gaithersburg, MD 20899-8970 > >Voice: 301-975-3262 >Fax: 301-590-9174 >Email: skall@nist.gov >****************************************************************
Received on Thursday, 16 January 2003 17:59:18 UTC