4. Conformance

This section defines conformance of Working Group processes and operations to the requirements of this specification. The requirements of this specification are detailed in the checkpoints of the preceding "Guidelines" chapter of this specification, and apply to the Working Group QA-related documents and deliverables required by this specification.

4.1. Normative parts

The following parts of this specification are normative:

Text that is designated as normative is directly applicable to achieving and assessing conformance to this document. Informative parts of this specification consist of examples, extended explanations, terminology, and other information that facilitates correct implementation of this specification.

4.2. Extensibility

This specification is extensible. That is, the Working Groups MAY set up quality-related processes and operations in addition to those required for conformance to this specification. Extensions to this specification MUST NOT contradict or negate the requirements of this specification.

The rationale for allowing Working Groups to define extensions to these operational guidelines is that these requirements are considered to be the minimal requirements for successful quality practices within the WGs. Doing more than the minimum is not only acceptable, but beneficial. Extensions also allow Working Groups tailor their quality practices more closely to their specific needs. The guidelines of this specification may not be sufficient to meet the needs of all WGs.

4.3. Conformance requirements & test assertions

Each checkpoint contains one or more conformance requirements. These are prefaced by "Conformance requirements:", highlighted in a different style (on appropriate media), and contain at least one of the RFC 2119 [RFC2119] keywords (MUST, SHOULD, MAY, etc).

This Operational Guidelines document does not enumerate a list of test assertions. Test assertions can be derived from conformance requirements in a straightforward manner.

4.4. Checkpoint priority definitions

Each checkpoint has a priority level based on the checkpoint's impact on the quality practices of a Working Group. The meanings of the priorities are:

[Priority 1]
Critical/essential. These checkpoints are considered to be basic requirements for ensuring that test materials are usable, and are produced in time to ensure the quality of the standard and its implementations. Satisfying these checkpoints is a basic requirement to ensure quality and interoperability of the standard.
[Priority 2]
Important/desirable. Satisfying these checkpoints, in addition to the priority 1 checkpoints, should significantly improve the usability and timeliness of the test materials, as well as the quality of the standard and its implementations.
[Priority 3]
Useful/beneficial. Satisfying these checkpoints, on top of all the others, will further improve the quality, usability, and timeliness of the test materials and the standard itself.

4.5. Conformance definition

This section defines three conformance levels to this guidelines specification:

This three-level conformance scheme (A, AA, AAA) was chosen in order to facilitate progressive (good-better-best) pursuit of the goals and benefits of these guidelines.

A checkpoint is satisfied by satisfying all of the individual mandatory conformance requirements. Mandatory requirements are those that use the conformance keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", or "SHALL NOT".

Note that it is allowed (even encouraged) to implement checkpoints in addition to those required to satisfy a particular degree of conformance (A, AA, or AAA). The more checkpoints that are satisfied, the better. However, there is no additional conformance designation for such intermediate collections of checkpoints (i.e., for all checkpoints of a given level plus some, but not all, of the checkpoints of the next levels).

The minimum recommended conformance to this specification is A-conforming -- all Priority 1 (critical/essential) checkpoints satisfied.

4.6. Conformance claims

An assertion of conformance to this specification -- i.e., a conformance claim -- MUST specify:

The priority-ordered checklist for this specification ([OPS-ICS]) is the Implementation Conformance Statement (ICS) pro forma for this specification. Any assertion of conformance to this specification MUST link to a completed ICS.

Example of a valid conformance claim:

The QA processes and operations of this FooBar Working Group, http://example.org/FooBar/, conform to W3C's 'QA Framework: Operational Guidelines', available at http://www.w3.org/TR/2003/WD-qaframe-ops-200302110/, on 23-April-2003, AA-Conforming. The Implementation Conformance Statement for this claim is available at http://example.org/FooBar/Test/OpsGL-ICS .

4.7. Conformance disclaimer

The checkpoints of this specification present verifiable conformance requirements about the operational aspects of Working Group quality processes. As with any verifiable conformance requirements, users should be aware of this disclaimer:

Passing all of the requirements to achieve a given conformance degree -- A, AA, or AAA -- does not guarantee that the subject operations and processes are well-suited to or will achieve their intended purposes, nor does it guarantee the quality or suitability of test materials produced under the processes.