- From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
- Date: Fri, 17 Jan 2003 08:50:21 -0500
- To: Lofton Henderson <lofton@rockynet.com>
- Cc: www-qa-wg@w3.org
Yes. It should be "i.e., no extensions". I was a bit sloppy, when I first sent this out. So it should now read..... Disallowing extensions for any part of the specification is called strict conformance. Strict conformance is defined as conformance of an implementation that employs only the requirements and/or functionality defined in the specification and no more (i.e., no extensions to the specification are implemented). I would like to keep this simple. Basically strict conformance = no extensions. If people think there is still confusion we could add the following with respect to DoV "Dimensions of variability (e.g., modules, profiles, levels) are not extensions if the specification defines them or allows them to be defined." My preference is not to add anything about DoV - I think that is what is adding to the confusion. IMO the confusion in Seattle and the issue, was because the text in GL3 was confusing, introduced confusion by talking about DoV and was using the definition of strict conformance erroneously in places. lynne At 08:15 PM 1/16/2003, Lofton Henderson wrote: >At 05:58 PM 1/16/03 -0500, Lynne Rosenthal wrote: > >>David >> >>I agree with Mark. I think you are reading way to much into strict >>conformance. > >I fell into this trap also, and I think it was because "e.g., no >extensions" in the verbiage is what stuck in my mind, instead of "i.e., no >extensions" (as it is in the glossary.) > >-Lofton. > >>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 Friday, 17 January 2003 08:59:05 UTC