Notes on Last Call Issues for SpecGL

[sent to www-qa, since there might be some interesting points to discuss
there if anybody is brave enough to read such a long email]	

Hi,

Here are my notes on the specGL LC issues (I only took in consideration
the 20 first ones noted as substantive)
http://www.w3.org/QA/WG/lc-issues

Issues regarding the scope of specGL:
- LC-1: should there be considerations about security?
- LC-55: should there be considerations accessibility?
Analysis:
This is clearly out of the scope of the document ["enhance the clarity,
implementability, and testability of TRs"] and of our charter ["* 
improving the quality of W3C specifications (with respect to conformance
statement, test assertions, tutorial/examples, formal representation of
languages, etc.)"]. The question is to know what we want to do with the
meta-issue of the needed features of a specification:
1. not address it
2. try to get some feedback from the chairs/the team if that something
that should be addressed, in what structure (coordination group?)
3. mention in an information section of our document the possible (but
not exhaustive) list of considerations not addressed by specGL
(typically in "Relationship to other specifications")
Proposed: 3 and maybe 2?

Degree of conformance of SpecGL to itself
- LC 14 stresses that we are not AA, and that we should aim AAA
Discussion:
It's arguable whether or not we fail CP 14.1 as presented by the
reviewer (because our conf req are so close to be test assertions), but
nevertheless, if they are so close, we should probably generate them
automatically in some way.
The second point is to know whether we should aim AAA or only AA. The WG
has decided we would aim to be AA for LC, we need to discuss our goals
for the future milestones, and we probably need to make our goal/claim
more explicit.

Usefulness of CP 1.4
- LC-23 has a specific proposal to break down the requirements per type
of specifications [meta-issue: are the categories defined in [2] classes
of product for specGL?]
Discussion: The proposal is interesting; since our classifications of
spec is probably not exhaustive, we would need to find a mechanism that
would allow to deal with non-identified categories (hmm... specGL
extensions ?)

Modules/Level/Profiles as separate DOV/GL?
- LC-30: the reviewer doesn't see any good reason to keep them
separated.
- [also related to] LC-74: consolidate specGL
Discussion:
Looking at the CP only reinforce this impression I've had for a long
time that the distinction we make is moot. (that is, the differences
that may exist behind "modules", "levels" and "profiles" don't seem to
imply any difference in the way they handled if you just characterize
them as "subsets"). I would be of the opinion to consolidate the 3 GL in
1. [this imply a fairly large change in the spec though, which may or
may not pose the question of the next stage for specGL]

Merging 9.1 and 9.2
- LC-38 suggests to merge 9.1 and 9.2; since the conformance requirement
of 9.1 is included in 9.2 (stating "the conditions under which
extensions are allowed"), this seems a rather obvious thing to do :)

Issues marked as Substantive but that I think are editorial:
- LC 5 ("Ck 2.2 list of classes") seems to show that our text is
confusing, but the requested change is already implemented in the
current spec
- LC 8 ("woolly" conformance req for 1.1): I'm not sure to understand
the issue, but it seems to more about the way we formulate it than the
things we require per se
- LC 9 ("Second sentence" isn't very clear, sadly)
- LC 11 
- LC 16 and 39 converge to say that the CP 8.4 is too hard to understand
- LC 18 (modules non-hierarchical): just need to add "non necessarily
hierarchical" or some such
- LC 21: clarification needed for the cross-DOV relationships DoV
- LC 28 (document organization suggestions)

Issues still needing work before discussion:
* LC-17: Necessity of grouping deprecated features in a section
-> we need a rationale to explain our decision to group them.
* LC-19: Importance of rules for profile
-> we need to give a better rationale than "experience shows" :)
* LC-29 poses a set of topics that are in scope of our work and that we
don't address; some would consist in techniques (how to export/import
requirements), others in modelling (characteristics of technical
requirements), and others in theorizing (good/bad extensions mechanisms,
performance requirements, configurability). Lots of work
* LC-37 suggests to remove the interdiction to contradict the spec,
because if you contradict the spec, you're not conformant anyway. The
intent of the CP seems to have been misunderstood, because of the
confusion between extension to an implementation vs extension to the
specification. Interestingly, our definition of "extension" is not very
helpful: "an extension to a specification is a mechanism to incorporate
functionality beyond what is defined in the specification" is wrong; an
extension is not a mechanism, it is a complement to an existing
specification. As such, we could consider it as a specification that
must comply with a set of requirements set by the original specification
* LC-40 suggests some considerations for obsoleted features; this
actually poses several questions: what are the relations between 2
versions of a ""technology"" (e.g. between HTML3.2 and HTML4.0)? is
versioning a Dimension of Variability? is the technology grouping that
underlies this question in or out of scope of specGL?

Non issues:
- LC 15 (a compliment :=)

Dom

1. http://www.w3.org/QA/WG/lc-issues
2. http://www.w3.org/TR/qaframe-spec/#document-categories
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org