QA Framework Specification Guidelines conformance to QA Framework Specification Guidelines

Introduction

This document consists of the table from QA Specification Guidelines - Implementation Conformance Statement, filled out as a conformance statement for QA Framework: Specification Guidelines, W3C Working Draft 22 November 2004, to itself. Although conformance only requires that all Requirements are met, (it is unaffected by Good Practice), the Good Practice entries have been filled in to more fully test the QA Specification Guidelines.

Although the QA Specification Guidelines do not seem to require this (perhaps they should?), an attempt has been made to link each "yes" to the part of the specification that meets the requirement (unless it is the entire specification). Failing this, a quotation from the specification is given in a footnote.

The issue of who is allowed to make conformance claims does not seem to be addressed.

Checklist table

Guidelines YES NO N/A
1 Specifying Conformance
1.1 A conformance clause is essential
Requirement : Include a conformance clause. YES (4)
Good Practice : Define the specification's conformance model in the conformance clause. YES
Good Practice : Specify in the conformance clause how to distinguish normative from informative content. YES
1.2 Specify how to make conformance claims
Good Practice : Provide the wording for conformance claims. YES
Good Practice : Provide an Implementation Conformance Statement proforma. YES
Good Practice : Require an Implementation Conformance Statement as part of valid conformance claims. not clear (2)
2. Setting up Groundrules
2.1. Scope
Requirement : Define the scope. YES (1)
Good Practice : Provide examples, use cases, and graphics. YES
2.2 What needs to conform
Requirement : Identify who or what will implement the specification. YES (3)
2.3 Normative (and non-normative) references
Requirement : Make a list of normative references. YES
Good Practice : Do systematic reviews of normative references and their implications. Probably (5)
4. Managing Variability
4.1 Subdivide
Good Practice : Create subdivisions of the technology when warranted. YES (6)
Requirement : If the technology is subdivided, then indicate which subdivisions are mandatory for conformance. n/a
So, should that be n/a or YES?
Requirement : If the technology is subdivided, then address subdivision constraints. n/a
So, should that be n/a or YES?
Good Practice : If the technology is profiled, define rules for creating new profiles. n/a
4.2 Optionality and Options
Good Practice : Make sure there is a need for the optional feature. n/a
Good Practice : Clearly identify optional features. n/a
Good Practice : Indicate any limitations or constraints on optional features. n/a
4.3 Extensibility and Extensions
Requirement : Address Extensibility. YES
Good Practice : If extensibility is allowed, define an extension mechanism. NO (7)
Good Practice : Warn implementers to create extensions that do not interfere with conformance. YES
Good Practice : Define error handling for unknown extensions. NO
4.4 Deprecation
Requirement : Identify deprecated features. Perhaps. (8)
Requirement : Define how deprecated feature is handled by each class of product. Perhaps. (8)
Good Practice : Explain how to avoid using a deprecated feature. n/a
Good Practice : Identify obsolete features. NO (9)
4.5 Error Handling
Good Practice : Define an error handling mechanism. NO
5. Do Quality Control
Good Practice : Define an internal publication and review process. YES (10)
Good Practice : Do a systematic and thorough review. YES (11)
Good Practice : Write sample code or tests. n/a or NO?
Good Practice : Write Test Assertions. Unknown
Good Practice : Use formal languages and define which from prose and formal languages has priority. YES

Footnotes

  1. It applies to one class of product – Working Group specifications (i.e., technical reports). Was not able to link to that statement.

  2. If all the Requirements are checked as being satisfied, then conformance can be claimed. does not say the converse. If (a) all the requirements are met, but a different form is filled in, or (b) if they are all met, but no form is filled in, and a claim is made; it is not clear whether conformance can be claimed. If the particular form must be used, why is [CONF-TEMPLATE] an informative reference?

  3. Not clear how that is different to scope. It applies to one class of product – Working Group specifications (i.e., technical reports).

  4. Using the defined term conformance model in the phrase Conformance to the QA Framework: Specification Guidelines is very simple would have made this slightly easier to check.

  5. This is something that in general, only the WG that produced the spec could answer, rather than being readily derivable from the specification. However, in this instance, there is only a single normative reference, RFC 2119, so it seems most probable that the use of must etc has been carefully considered.

    For a more typical specification with considerable number of normative references this would be a harder thing to determine. The single RFC 2396 example given is good, perhaps 'which version of Unicode' and 'XML 1.0, 1.1, or infoset' would be other good, and common, examples.

  6. The corollary is, presumable "or state that no subdivision is warranted" which is the case for the QA Framework. It would be preferable to make that a little more explicit. If a technology is not subdivided, should it be explained why not? If there is no explanation, and there is no subdivision, can conformance be claimed?

  7. No extensibility mechanism is presented, although one constraint on extensibility is discussed: Extensions to this specification must not contradict nor negate the requirements in this specification. No mention is made of who may extend the QA Specification Guidelines (the QA Working Group) or the mechanism (publish a second edition or a new version).

  8. No deprecated features are listed. Its not clear if that is sufficient, or if a positive statement "there are no deprecated features" is required.

  9. No obsolete features are identified. Probably because there are none, but should there not be a positive requirement to state that there are no obsolete features, rather than not saying anything?

  10. Proof of this happens to have been provided by an example. In general it would be harder to demonstrate this, particularly in a public draft of a spec and a non-public working group.

  11. Proof of this happens to have been provided by another example.

Chris Lilley <chris@w3.org>
$Id:$