- From: David Marston/Cambridge/IBM <david_marston@us.ibm.com>
- Date: Fri, 1 Nov 2002 00:39:33 -0500
- To: www-qa-wg@w3.org
Below is my attempt to put more focus into the checkpoints of Spec Guideline 6, the thing which started out as the "flavors" guideline. It's moving in the direction of not being a DoV unto itself, though it still is in this version. It continues to present ideas and rationales that relate to other DoV individually. I rearranged a couple pieces and changed wording to draw out the idea that this guideline is about minimum and maximum feature sets, but that other DoV can interact with that notion. In particular, an implementation can exceed the high end of the spec in ways other than adding extensions, which is why this guideline doesn't collapse into GL 9. I also added rationales related to test suites. Apart from the content, I propose that this Guideline be moved up to become GL 3, with the current 3-5 becoming 4-6. Those who read SpecGL sequentially will thus encounter this guideline (about conformance policy at the strategic level) just after the material about Class of Product and before all the other DoV. Let the next WD go out with this guideline still present, but think again later about whether and how to move its provisions into other guidelines. .................David Marston Guideline 6. Specify conformance policy. A look at various W3C Technical Reports shows that the term "conformance" is often qualified, resulting in more than one type of conformance. It is important to convey an understanding of what is meant by conformance and where the products of a class are allowed to have more, less, or different functionality from one another. If the specification defines behavior for more than one class of product, there may be a separate conformance policy for each class. Often, the specification will allow discretionary choices, such as the choice of date-time formats, but require a conforming product to make a choice only within the allowable range. (See Guideline 8 for more discussion.) Sometimes a product developer can choose to implement certain modules. There may be per-module conformance requirements that apply if and only if the developer chooses to implement a particular module. Sometimes a product developer can choose to implement extensions. There may be conformance requirements for non-interference of extensions. (See Guideline 9 for more discussion.) Where all products of a class must be substantially alike, it should be clear that a "strict conformance" policy is in effect for that product class. 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. Overall, the intent of the WG should be clear. In particular, a reader intending to implement a product in one of the product classes addressed by the specification should know what the WG wants for interoperability among products in the class. The developer should understand what forms, if any, of "product differentiation" are allowed among conformant products. The specification may need to explain how the rules apply and possibly provide examples. Guideline 10, "conformance clause" is related to this guideline. This Guideline 6 focuses on the establishment and scope of a conformance policy, while Guideline 10 focuses on where and how to document it. That is, the verification of these checkpoints will require looking at the Conformance Clause. Checkpoints Checkpoint 6.1. Specify any universal requirements for minimum functionality. [Priority 1] To fulfill this checkpoint, a specification MUST include a normative section detailing any universal requirements for minimum functionality. It is not applicable if there aren't any universal requirements. Rationale: the reader must be able to recognize any minimum that applies to all conforming products of each class. The test suite can have a core of universal test cases. If levels are used (see Guideline 5), the lowest level may represent the minimum set of requirements. If profiles are used (see Guideline 3), there may be different minima for each profile. If modules are used (see Guideline 4), there may be different minima for each module. Furthermore, a module may itself be a minimum (i.e., required) for a particular class of product. Checkpoint 6.2. Identify strict conformance requirements. [Priority 1] To fulfill this checkpoint, a specification MUST state in its conformance section if the conformance requirements are strict or identify the kinds of variability that are permitted. Rationale: the reader must be able to recognize when a policy of "strict conformance" applies. As defined above, this implies that all conformant products of a class behave essentially the same way. Tailoring of the test suite will be confined to selecting a portion applicable to the product class (or profile or module, as explained below). Strict conformance can apply separately to each class of product addressed by the specification. If profiles are used, each profile may have its own conformance boundaries. If modules are used, each module may have its own conformance boundaries. Some profiles or modules may have a strict conformance policy while others do not. Use the definition provided above (or in the QA Glossary [QA-GLOSSARY]). The definition may be modified to adjust its scope, for example when applying it to modules or profiles. In such cases, the scope of "requirements [...] defined in the specification" is narrowed from the whole specification to the module or profile that is the target of the statement. Checkpoint 6.3. Distinguish requirements from product-specific extra features [Priority 1] To fulfill this checkpoint, a specification MUST state in its conformance section all facets of the requirements where the required features represent the maximum allowable capabilities. Rationale: When a strict conformance policy applies, the maximum set of features is the same as the minimum. When strict conformance does not apply, implementations may be allowed to exceed the specified capabilities in ways other than having extensions. (Example: a graphical capability may be specified with a required resolution or a set of resolution levels that must be supported. The specification may wish to require that implementations not create images of higher resolution due to concerns about excessive size.) The specification SHOULD identify the facets in which an implementation may add more features, if there is a history of expanding features for those facets. If profiles are used (see Guideline 3), state whether extra capabilities of the platform may be exploited. If modules are used (see Guideline 4), there may be different provisions for extra features applying to each. If levels are used (see Guideline 5), state whether the highest level may be exceeded with additional features or functionality. If deprecation applies (see Guideline 7), make it clear whether support of the obsolete features is optional, part of a level, part or all of a module, or required. If discretionary choices are allowed (see Guideline 8), make it clear if more than one may be implemented, when it is technically possible to do so. Checkpoint 6.4. If special conformance terms are used, include a definition in the specification. [Priority 1] To fulfill this checkpoint, a specification MUST either exclusively use conformance terms as defined in this document or define any other conformance terms used in it and reference them from the conformance clause. Rationale: it is necessary to define terms that govern application of the conformance provisions. Ideally, all terms are from QA documents and other existing literature and need only be cited. If special terms are constructed, such as to combine modules and levels or modules and discretionary choices, they need to be defined in the specification.
Received on Friday, 1 November 2002 00:47:20 UTC