Re: SpecGL problems/issues to be addressed

A new concern issue, and I have also gathered previous comments on some of 
the remaining open ones...

First
-----

I have one other concern, to add to your list.  In response to issue #69 
(Connolly) we determined "SpecGL warns about too much DoV and requires that 
specs explain of why they need a particular DoV."  We used to have (SpecGL 
20020826) some warning words at each DoV guideline.  Now, that is all gone 
and there is just one mention in the whole document, in the last paragraph 
of sec 1.8.

Issue:  is that sufficient?

Ref:  http://www.w3.org/QA/WG/qawg-issues-html#x69
Ref:  http://www.w3.org/QA/WG/2002/10/qaframe-spec-20021025#variability

Second
-----

Some previous comments are embedded again below...

At 11:32 AM 10/31/2002 -0500, Lynne Rosenthal wrote:
>[...]
>
>The following still need to be addressed
>
>*2.2:  move discussion on class of product to ET
>*2.2    reword CP or its TA

>  *2.2:  move discussion on class of product to ET

This is one of those "negative disclaimer" sorts of statements.  If we can 
clarify what we mean a little better, then I think it is more useful here 
than in ET.  Can we clarify?  Does it mean, "[what is in scope and] what is 
out of scope of the conformance requirements?".  What it now says is, "it 
may be appropriate to specify that which is not a requirement", which I 
don't understand.  Can someone give an example?

>   *2.2    reword CP or its TA

No opinion on the specific question.

But ... do we really mean to limit it to "the Introductory section"?  I 
agree that it might want to be up front.  At least, it would be better to 
say "in an introductory section".  (Would the spec fail this CP if the 
authors put it in their "Scope & goals" section, which seems a reasonable 
place?  Or in their "Conformance" chapter?).

>3.3     do we need a rationale or write a better one

See threads:

http://lists.w3.org/Archives/Public/www-qa-wg/2002Oct/0127.html
http://lists.w3.org/Archives/Public/www-qa/2002Oct/0021.html

3.3 "@@@so?"...  Currently the rationale is "a profile places requirements 
on each class of product that is affected by the profile's definition".  I 
agree that it's a bad rationale.  But I have another problem.  The 
statement of the CP is in terms of "must define minimal required 
support/features for each class of product".  What does "minimal required 
support/features" mean, and how would it differ from "complete set of 
conformance requirements", and which one do we really want?

>7.2     reword CP or its TA - suggested CP reword: Define support 
>requirements for deprecated features"
>7.3     applicability of CP to class of product

(Note. 7.4, not 7.3). Thoughts

1.) yes, it is okay (if the assertion is true about "producers") -- its 
applicability ought to be clarified and qualified.

2.) is the assertion true? seems like it. But ... how about this scenario? 
ZML 2.0 deprecates feature "Blah", and explains that producers can achieve 
the same effect by generating "Foo" and "Bar". Doesn't this also tell ZML 
2.0 consumers that they can handle ZML 1.0 content by mapping Blah to Foo+Bar?

>G9 rewritten, general consensus

I keep thinking that there is a nice way to combine CK9.1 and 9.2, without 
losing any requirements. For example,

9.1: "Define whether or not conformance is strict."
(Subsumes the "if allowed" and "not allowed" parts of 9.1 and 9.2)

9.2: "If extensions are allowed, completely define their scope and 
constraints".

That does not seem to lose any requirements, does it?  (Then, notice how it 
interacts with 6.x, the "strict conformance" checkpoint.)

Third
-----
(some new comments)

>9.6  applicability, remove?

I don't understand the question.  What is the "applicability section".

Another comment (new):  I believe that it is our intention to say "only 
strictly conforming content", not "only conforming content".  I.e., content 
without extensions.  (Example.  SVG 1.0 content with private foreign 
namespace elements and attributes is conforming and valid.)

Yet another (new).  In 9.4, "a specification MUST provide a standard way of 
defining the extension".  This is potentially confusing -- are we talking 
about the specification, or are we talking about spec's conformance 
requirements on implementations that contain extensions?  Or both?  On 
short notice, I don't have improved wording.  Maybe something like "a 
specification MUST define a standard syntax [or method or some other word] 
for expressing extensions, and MUST require that conforming implementations 
use that standard [...whatever...].

>13.1 add words on capitalization

(New).  I'm unclear -- are we suggesting that UPPER CASE (note -- not 
Capitalization) be required?  Or that the spec make and document a clear 
choice?

>13.3 testability of consistent terminology

(new.) IMO, the "identical" part can be made testable.  The "analogous" 
part is harder (unless some can figure out a testable expression, the idea 
could be moved to "Discussion" with a lower-case 'recommended'.)

>**14.1 TA discussion on normativity
>

-Lofton.