QA Review of Review of CSS3-UI

Editors:: Karl Dubost for the QA Working Group (www-qa@w3.org)

Status of this document

This document is a review of CSS3 Basic User Interface Module (W3C Working Draft 3 July 2003) against the QA Framework: Specification guidelines. If you need to discuss about this review, please, do it on the www-qa mailing-list (www-qa@w3.org).

This checklist includes all checkpoints from the QA Framework: Specification Guidelines [QAF-SPEC] presented in a tabular format. The checkpoints are presented by order of their priorities, which makes it an appropriate Implementation Conformance Statement for the guidelines.

General Comments

A new version of the QA Framework spec guidelines should be released soon and will have differences with the one used here. This review is intended to help you, not to block you. If needed we could make another review with the new version of the QA Framework which will stay in an implementation phase for one year.

Question about Abstract

You have written The ability to style the appearance of various standard form elements in HTML4 and properties to augment or replace some remaining stylistic attributes in HTML4. Could it be misleading for developers that it doesn't address XHTML 1.0 or XHTML 1.1 or any future versions of XHTML?

How to read the comments in the table.

We have decided to make a difference between negative answers when you do not comply. CSS3-UI is a module of a bigger set as you have written in the status section: This document is a draft of one of the "modules" for the upcoming CSS3 specification.. One issue is to establish if you do conform to the QA Specification Guidelines. It is impossible if we consider only this specification. It might be a QA issue. A mail will be sent to www-qa@w3.org

It raises the question if a WD of a modular set can reach the status of W3C Recommendation if other parts are still at another stage.

If yes, it means that the QA Spec Guidelines have an issue making it impossible to apply.

If no, it means that the CSS WG will have to define the master document which defines the missing part before to go to final stage.

So There will be a lowercase no when it's dependent on the master specification and a uppercase NO with red background when it's an issue of this module only.

Checklist table

Degree A Conformance

To be A-conformant with the guidelines, the following Priority 1 checkpoints must be fulfilled:

Nbr	Checkpoint	Yes	No	N/A
Guideline 1. Define Scope.
1.1	Include the scope of the specification.	YES
Guideline 2. Identify what needs to conform and how.
2.1	Identify all classes of product.		no: there's no mention of the products which should implement it. You do not define also what's an UA. No glossary for this acronym.
2.2	For each class of product, define the conformance requirements.		no: See General comments.
Guideline 3. Specify conformance policy.
3.4	If special conformance terms are used, include a definition in the specification.		no: See General comments.
3.5	Justify any usage of a dimension of variability by reference to usage scenarios and requirements		no: See General comments.
Guideline 4. Address the use of profiles to divide the technology.
4.1	Indicate whether or not the use of profiles is mandatory for conformance.		no: See General comments.
Guideline 5. Address the use of modules to divide the technology.
5.1	If modules are chosen, indicate any mandatory conditions or constraints on their usage.		no: See General comments.
Guideline 7. Identify the relation between deprecated features and conformance.
7.1	Identify each deprecated feature.		NO: this is a very tricky case. It's not exactly a deprecated feature but a redefinition of another technology behaviour. How people are supposed to implement them. How User Agents should implement HTML 4.01 with CSS3-UI when the two compete?	N/A
7.2	For each class of product, specify the degree of support required for each deprecated feature and the conformance consequences of the deprecation.			N/A
Guideline 8. Define discretionary items.
8.1	State the circumstances for when discretionary items are allowed		no: See General comments. it seems that any features could be discretionary. It's dependant of your notion of profiles, in this case but you haven't defined the profiles.
8.2	For implementation dependencies, address the allowable differences between implementations	YES
Guideline 9. Allow extensions or NOT!
9.1	Indicate if the specification is extensible.		NO: You should define if the extension are allowed or not. State it.
9.2	If extensions are allowed, define their scope and constraints.			N/A: just because we don't know if the specification is extensible or not.
9.3	Prevent extensions from contradicting the specification.			N/A: just because we don't know if the specification is extensible or not.
Guideline 10. Provide a conformance clause.
10.1	Include a conformance section.		no: See General comments. You didn't provide any conformance clause. You have to give one explaining how the different classes of products should conform to your specification. Make a reference to the conformance section in this spec to the one where it will be defined.
Guideline 11. Specify how to make conformance claims.
11.1	Identify and define all conformance designations.			N/A: Only because you don't have any conformance sections.
11.4	Impose no restrictions about who can make a claim or where claims can be published.			N/A: No conformance section.
Guideline 13. Clearly identify conformance requirements.
13.1	Use conformance key words.		no: See General comments.
13.2	Distinguish normative and informative text.		NO: You do not define the section of your documents which are normative. Please add after each section, a word to show that this part is normative, or that part is informative.
13.3	Use consistent terminology.	YES: It seems correct. Define the terms which are not defined or acronyms.

Degree AA Conformance

To be AA-conformant with the guidelines, the following Priority 2 checkpoints must be fulfilled (in addition to the above Priority 1 checkpoints):

Nbr	Checkpoint	Yes	No	N/A
Guideline 1. Define Scope.
1.4	Provide examples.	YES
Guideline 3. Specify conformance policy.
3.1	Specify any universal requirements for minimum functionality.		no: See General comments.
Guideline 4. Address the use of profiles to divide the technology.
4.2	If profiles are chosen, define any minimal requirements.		no: See General comments. Profiles are chosen but we are unable to determine how they will work.
4.3	If profiles are chosen, define their relationships and interaction with other dimensions of variability.			N/A. To be defined.
4.4	If profiles are chosen, address rules for profiles.			N/A. To be defined.
Guideline 5. Address the use of modules to divide the technology.
5.2	If modules are chosen, define their relationships and interaction with other dimensions of variability.	YES
Guideline 6. Address the use of functional levels to divide the technology.
6.1	If levels are used, define their relationships and interaction with other dimensions of variability.	YES
Guideline 8. Define discretionary items.
8.3	Indicate any constraints on the number of choices/options that can be implemented for discretionary choices		no: See General comments.
8.4	Promote consistent handling of discretionary choices.		no: See General comments.
Guideline 10. Provide a conformance clause.
10.2	Make normative reference to specifications on which the current specification depends	YES
Guideline 13. Clearly identify conformance requirements.
13.4	Provide a fast way to find conformance information		no: See General comments.
Guideline 14. Provide test assertions.
14.1	Provide test assertions		NO: You have a test suite, but you don't provide in this document a way to know what is testable.
14.2	Provide a mapping between the specification and the test assertions list		NO: You don't have this list.

Degree AAA Conformance

To be AAA-conformant with the guidelines, the following Priority 3 checkpoints must be fulfilled (in addition to the above Priority 1 and Priority 2 checkpoints):

Nbr	Checkpoint	No	N/A
Guideline 1. Define Scope.
1.3	Provide Usage Scenarios.	NO
Guideline 2. Identify what needs to conform and how.
2.3	Identify which of the categories of object are specified in the document as a whole.	no: See General comments.
Guideline 7. Identify the relation between deprecated features and conformance.
7.4	Include an explanation for the deprecation.	NO: not always. (wrt HTML 4.01)
7.5	Include examples to illustrate how to avoid using deprecated features.	NO
Guideline 9. Allow extensions or NOT!
9.4	Define a uniform mechanism to create an extension.	NO
9.5	Require that extensions be published.		N/A. because not defined.
9.6	Require that implementations provide interoperable alternatives to extensions		N/A. idem.
Guideline 11. Specify how to make conformance claims.
11.2	Provide specific wording of the claim.	no: See General comments.
11.3	Provide a conformance disclaimer.	no: See General comments.
Guideline 12. Publish an Implementation Conformance Statement proforma.
12.1	Provide an Implementation Conformance Statement proforma.	no: See General comments.
12.2	Require the ICS be completed as part of the conformance claim.	no: See General comments.

References

QAF-SPEC: QA Framework: Specification Guidelines, D. Hazaël-Massieux, L. Henderson, L. Rosenthal, D. Dimitriadis, K. Gavrylyuk, Eds., W3C Working Draft, January 2003, available at http://www.w3.org/QA/WG/qaframe-spec.

Created Date: 2003-07-31 by Karl Dubost >karl@w3.org>
Last modified $Date: 2004/03/02 01:22:05 $ by $Author: kdubost $

Copyright © 2000-2003 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.