Editorial thoughts on qaframe-spec

[sent to the WG list because this is mostly editorial stuff, but please
send any technical reply in CC to www-qa]

Hi folks,

I hope you all had a safe trip back; I really enjoyed last week meeting
and think it was really productive.

I've started working on the new version of qaframe-spec, and have a few
thoughts to share.

First thing I'm trying to do is to harmonize and formalize our
checkpoints, which consists in:
- producing test assertions for each CP with a capitalized RFC2119
keyword; most of the time, I try to use MUST and reserve SHOULD for
assertions we're not sure how broad their usage is. I've not used MAY so
far and don't think we should
- using consistent verbs between CP (define, provide, describe,
identify, indicate), removing non testable adverbs and phrases (clearly,
make it clear, ...)
- distinguishing examples and rationales, so that it's easier later to
see what's normative and what's informative only

[the draft I'm working on is available at
http://www.w3.org/QA/WG/2002/09/qaframe-spec-inprogress.html ; its
default stylesheet shows everything that has been inserted and deleted,
there is an alternate stylesheet available for a lighter reading]

I have not worked at all on the introductory section, since I think
Lofton plans to do it. I'll try to propose a plan for this section ASAP.

As now I have to work on the DOV GL (currently GL 3,4 and 7), I have
thought of a new way to understanding these GL and would like to get
feedback on this, especially from Lynne and Lofton. The current pb is:
- we have had difficulties separating what concerns the technology and
what concerns the specification in GL 3, 4, and 7
- some CP speak about entries in TOC, but it's not clear to which TOC
these CP apply; in the case of profiles, this could be the "main" spec,
a specific profile, the rules for profiles

My view on this is that we are actually treating the same way 2 very
different issues:
- specifications defining one or more [modules,levels,profiles]
- specifications "using" (that is, inheriting features defined by) one
or more [modules, levels, profiles]

The confusion between the 2 issues is easy to make since often, a
specification matches this 2 categories (e.g. CSS TV Profile defines a
profiles, using CSS Modules).

A related issue that we don't clearly address but that we probably
should is the question of subsetting a specification (does the spec
allow it? if yes, under what rules? ...)

I'll try to see if I can find a good way to match this in a new
structure for GL 3, 4 and 7, but any comment in the meanwhile is
welcomed :)

Dom
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/INRIA
mailto:dom@w3.org