comments on SpecGL LC issues

For discussion: Last Call issues SpecGL.
The issue, discussion and alternatives are provided for a few of the 
related issue groups identified by Lofton 
(http://lists.w3.org/Archives/Public/www-qa-wg/2003Apr/0020.html )

1.  EXAMPLES, USE CSES,  etc
    23: usefulness of CP1.4
    75.1: reorder CP 1.3 and 1.4 (increasing priority)
    92: difference between CP1.2 and CP1.4
    79: fail CP 1.2 and 1.3
    77.ET2:
LC-23: Usefulness of CP 1.4 (from Dom)
 > - 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 ?)
This CP has been rewritten several times, from a more specific requirement 
to this one.
Alternatives:
1. Implement the proposal  make more specific requirements and tie it to 
specification categories.
2. Implement the proposal in the ExTech document, but leave CP as is
3. Implement the proposal in the ExTech document, and make CP more specific 
without mentioning categories. (I'm not sure how we do this)
Recommend #2 but if someone can make the CP more explicit  great.

LC-75.1: reorder CP 1.3 and 1.4, so listed in priority order
Discussion: CP 1.3 (P3) address a broader scope than CP1.4 (P2).  Thus, the 
CPs of Guideline 1 go from broad (the spec as a whole) to more narrow 
aspects (each behavior or functions)
Alternatives
1. Reverse CP 1.3 and 1.4
2. Leave as is

LC  92: Difference between CP 1.2 and CP 1.4
Discussion: CP1.2 requires examples of what is in scope; CO 1.4 requires 
examples of specific functionality, concepts, behavior.  Need to make this 
clearer, perhaps remove 'concepts' from CP 1.4 will help
Alternatives:
1. Clarify the difference  that 1.2 is broader examples, whereas 1.4 is 
very specific to a function or behavior.
2. Remove CP 1.4
3. Remove CP 1.2

LC-79: fails CP 1.2 and CP 1.3  no examples and usage scenarios given
Discussion: examples are not given for what is in scope, nor are usage 
scenarios given.  This was probably due to lack of resources (someone) to 
write these.  Do we still believe that a spec should include these?
Alternatives
1. Add examples and/or use cases, and provide usage scenarios
2. No need to, these are "not applicable" to SpecGL
3. No need to, SpecGl only needs to conform to itself at level "A 
Conforming" (only P1 checkpoints)
Recommend: #1. We should do what we require other specs to do and conform 
at level AAA

LC-77.ET-2

DEPRECATION:
    33:  Editorial: "used" may not be specific enough term.
    40: add obsolete features
    99: CP7.3 can't meet requirement due to reason for deprecation
LC-40:  Include discussion of obsolete features
Discussion: Similar to deprecation, it is also important to identify the 
relation between obsolete features and provide alternatives to them. E.g., 
HTML 4.0 made obsolete a few elements.
Alternatives:
1. Add a new Guideline to address obsolescence, with same checkpoints as 
Deprecation
2. Include obsolescence with deprecation  add 1 or 2 checkpoint on obsolete 
features in the Guideline
3. Broaden the scope of deprecation to include obsolescence  so each 
checkpoint applies to deprecated and obsolete features.

LC-99 CP7.3 awkward requirement
It is likely that some things are deprecated precisely because they cannot 
be well defined and unambiguously characterized. There may not be agreement 
on its relation and interaction with other DoV  that may be why it is being 
deprecated. (catch 22?)
Alternative:
1. Remove the CP
2. Add a rationale and techniques in ExTech

WHAT IS NORMATIVE       (editorial)
    LC-  36, 65, 106, 108
It is unclear which sections, paragraphs, and sentences are normative.  Is 
the Glossary (sec 4 Definitions, or external Glossary) normative? Section 
3.1, "following sections are normative" then identifies sentences, and 
paragraphs that are normative.  RFC 2119 terms are not normative, but the 
use of the keywords indicates normative sentences. Priority levels are not 
normative.    In Section 2, only the Conformance Requirements are 
normative, Section 3 is Normative,  Is Section 1 Normative?
Alternatives
1. change definition of  Normative (dependent on someone supplying a new 
definition)
2. leave definition as is.
3. label all sections, as part of the section title and delete section 3.1
4. reword section 3.1 and label paragraphs, sections, etc that are normative.
Recommend: #4and #1


CP 8.4 CONSISTENT HANDLING of DISCRETIONARY CHOICES
     LC-16, 39: What does this mean
Discussion: comments regarding "document the identified policies".  Needs 
to be clarified and if possible, made simpler.  This CP has been rewritten 
several times.  It seems to be a difficult concept to describe clearly and 
with broad application.
Alternatives
1. try again, and rewrite (volunteers?)
2. delete the checkpoint
3. leave it as is.

SECTION NUMBERING  Editorial
LC-63, 91
Better way to number Sections and guidelines/CP and list in Table of 
Contents.  How does Accessibility Guidelines do this?