- From: Mark Skall <mark.skall@nist.gov>
- Date: Fri, 17 Jan 2003 09:42:26 -0500
- To: Lynne Rosenthal <lynne.rosenthal@nist.gov>, Lofton Henderson <lofton@rockynet.com>
- Cc: www-qa-wg@w3.org
At 08:50 AM 1/17/2003 -0500, Lynne Rosenthal wrote: >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." I like this. it states unequivocally what some of us have been saying. >My preference is not to add anything about DoV - I think that is what is >adding to the confusion. I still think there is confusion, based on the discussion. I think it's a mind set (the term "strict" in "strict conformance" implies, in some people's mind, an exact match of all implementations, and thus equivalent DOVs). Thus, I think the sentence you suggested would eliminate any 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 >>>>**************************************************************** **************************************************************** 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 09:50:53 UTC