The continuing saga of Spec Guideline 6

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