Re: SpecGL problems/issues for telcon 28 Oct

Here are some comments on the 10/25 SpecGL issues (and "@@@" flags)...

At 11:18 AM 10/25/02 -0400, you wrote:
>The following are a list of the problems/issues identified in the latest 
>version of SpecGL http://www.w3.org/QA/WG/2002/10/qaframe-spec-20021025
>and marked by @@@.   I've indicated the items I think are the highest 
>priority.  Unless someone suggests indicates a preference/priority, my 
>intention is to address the ** in order
>
>SpecGL problems/issues
>
>** indicates priority.
>* indicates we can deal with this quickly
>
>*G 1:  explanation and clean-up of sentence on use cases (editorial)

The parenthetical "(specification)" is an indication of uncertainty about 
how the generic "use cases" definition was adapted to SpecGL.  The original 
word "system" came from some (???) definition.  What is the "system in this 
context?

>   1.3:   make the statement stronger.  Currently requires only 1 example

I think it should be made stronger, but don't know how to do it.  Some time 
we said, "example per major feature", but the latter could be tricky to 
define.  "at least 1 example" is pretty feeble.

1.4:  "definition of 'formal description' needed" -- is someone already 
assigned to do this?

>  *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.1  TOC for profiles
>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?


>**3.5  what is meant by 'testable rule' 'clash'

@@@ what is a testable rule:  "rules" could probably be replaced by 
"requirements", or (better, I think) defined in terms of requirements (the 
objects being profiles themselves).  Then ... we have a definition of 
"testable requirement" that arose in our friendly discussion of "testable 
specification" (Tokyo, and see issue #81)


>**6.2  rationale for CP on strict conformance
>**6.3  rationale

See threads:

http://lists.w3.org/Archives/Public/www-qa-wg/2002Oct/0128.html
http://lists.w3.org/Archives/Public/www-qa-wg/2002Oct/0130.html
http://lists.w3.org/Archives/Public/www-qa-wg/2002Oct/0131.html

Clash:  contradict, redefine, ... (add a few more bad things, if you can 
think of them).
>7.2     reword CP or its TA
>
>7.3     applicability of CP to class of product
>G9 rewritten, general consensus
>9.6  applicability, remove?
>**12.1  normative ICS
>  **12.2  more ICS

See thread:  http://lists.w3.org/Archives/Public/www-qa-wg/2002Oct/0117.html

>13.1 add words on capitalization
>13.3 testability of consistent terminology
>**14.1 TA discussion on normativity
>