W3C home > Mailing lists > Public > www-qa-wg@w3.org > March 2005

[SpecGL] Table Old to New Scheme

From: Karl Dubost <karl@w3.org>
Date: Wed, 16 Mar 2005 19:23:59 -0500
Message-Id: <96dd779c84f35c3a7c4cfff8fb24772d@w3.org>
To: 'www-qa-wg@w3.org' <www-qa-wg@w3.org>
This is the table of references between Old Spec Gl
	http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/
and the future new published version.

1.1 Req A	Requirement 01: 	Include a conformance clause.
1.1 GP B	Good Practice 01: 	Define the specification's conformance model
								in the conformance clause.
1.1 GP C	Good Practice 02: 	Specify in the conformance clause how to
								distinguish normative from informative content.
1.2 GP A	Good Practice 03: 	Provide the wording for conformance claims.
1.2 GP B	Good Practice 04:  	Provide an Implementation Conformance
								Statement Proforma.
1.2 GP C	Good Practice 05:  	Require an Implementation Conformance 
Statement
								as part of valid conformance claims.
2.1 Req A	Requirement 02: 	Define the scope.
2.1 GP B	Good Practice 06: 	Provide examples, use cases, and graphics.
5 GP C  	Good Practice 07: 	Write sample code or tests.
2.2 Req A	Requirement 03: 	Identify who or what will implement
								the specification.
2.3 Req A	Requirement 04: 	Make a list of normative references.
2.3 GP B	Good Practice 08: 	Do systematic reviews of normative 
references
								and their implications.
3.1 Req A	Requirement 05: 	Define the terms used in the normative parts
								of the specification.
3.1 Req B	Requirement 06: 	Create conformance labels for each part
								of the conformance model.
3.1 GP C	Good Practice 09: 	Define the unfamiliar terms in-line,
								and consolidate the definitions in a glossary section.
3.1 GP D	Good Practice 10:	Use terms already defined without changing
								their definition.
3.2 Req A	Requirement 07: 	Use a consistent style for conformance
								requirements and explain how to distinguish them.
3.2 Req B	Requirement 08: 	Indicate which conformance requirements are
								mandatory, which are recommended and which are
								optional.
5  GP E		Good Practice 11: 	Use formal languages when possible
5  GP D		Good Practice 12: 		Write Test Assertions.
4.1 GP A	Good Practice 13: 	Create subdivisions of the technology
								when warranted.
4.1 Req B	Requirement 09: 	If the technology is subdivided, then
								indicate which subdivisions are mandatory
								for conformance.
4.1 Req C	Requirement 10: 	If the technology is subdivided, then
								address subdivision  constraints.
4.1 GP D	Good Practice 14: 	If the technology is profiled, define rules
								for creating new profiles.
4.2 GP A	Good Practice 15: 	Use optional features as warranted.
4.2 GP B	Good Practice 16: 	Clearly identify optional features.
4.2 GP C	Good Practice 17: 	Indicate any limitations or constraints on 
optional features.
4.3 Req A	Requirement 11: 	Address Extensibility.
4.3 GP B	Good Practice 18: 	If extensibility is allowed, define an
								extension mechanism.
4.3 GP C	Good Practice 19: 	Warn extension creators to create extensions
								that do not interfere with conformance.
4.3 GP D	Good Practice 20: 	Define error handling for unknown 
extensions.
4.4 Req A	Requirement 12: 	Identify deprecated features.
4.4 Req B	Requirement 13: 	Define how each deprecated feature is
								handled by each class of product.
4.4 GP C	Good Practice 21: 	Explain how to avoid using a deprecated 
feature.
4.4 GP D	Good Practice 22: 	Identify obsolete features.
4.5 GP A	Good Practice 23: 	Define an error handling mechanism.

5GP A, B 	to Beyond Conformance



-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***

Received on Thursday, 17 March 2005 00:24:09 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:13:20 GMT