Re: The continuing saga of Spec Guideline 6

I agree with the idea of moving GL3 up to GL6 -- but I'd leave that change 
to the editor's discretion for this week's publication.  If there is too 
much other SpecGL stuff to tend to, we could delay it.  I also agree that 
we ought, after publication, to revisit whether this should be a separate 
guideline.

I would like to see, in the guideline verbiage, an expression of the idea 
that this guideline is a "catch-all", a phrase you used in an earlier 
mail.  It is a guideline that gathers together details of conformance 
policy that don't fit into one of the more narrowly focused guidelines 
(this idea helped me to make sense of it).  For that reason, I'm not sure 
that we should try to classify it so carefully, i.e., "minimum and maximum 
features sets".

For example, in another mail, you gave an example from XSL where a rule was 
claimed, "more specific prevails", that was never documented in XSLT.  I 
would see this GL as a possible place for a checkpoint that would try to 
flush out such "any other miscellaneous rules about conformance 
policy."  This fits with your statement, "Overall, the intent of the WG 
should be clear.", but does not deal with feature sets or 
minima-maxima.  It is close to CK6.4, in one sense, but it is focused on 
terminology and not "miscellaneous conformance rules" (like, higher 
specificity prevails).

-Lofton.

At 12:39 AM 11/1/2002 -0500, David Marston/Cambridge/IBM wrote:
>[...]
>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 Sunday, 3 November 2002 22:51:36 UTC