Proposed processing plan for specGL issues (was: Notes on Last Call Issues for SpecGL)

[removing www-qa, since this is mostly for Monday's telecon]

Here is the thing that we need to discuss among this notes:
> Issues marked as Substantive but that I think are editorial:
-> do we agree on this re-casting?
-> volunteers to draft the needed changes?
> Issues still needing work before discussion:
-> do we agree on the characterization of these issues?
-> volunteers to work on them?

Once this discussed, we can probably discuss the following proposals:

> 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 :)

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