Re: OpsGL CP1.1 commitment table

DM>>I agree that (1) and (2) can be retained. I notice that since the
DM>>original version,

LH>...by which, do you mean your original email, from which this is
LH>all derived? [1]
LH>[1] http://lists.w3.org/Archives/Public/www-qa/2001Apr/0004.html

Yes.

DM>>The big chasm seems to be between Levels 4 and 5, since I gather
DM>>that Level 5 is where we start to think about completeness. If
DM>>that's the intent, then the word "complete" should be there, or
DM>>its equivalent that satisfies the critics. But QAWG needs to think
DM>>about whether (attempted) completeness is too hard to tie to
DM>>Priority 2.

Note that the chasm was between Levels 7 and 8 on my original 0-12
scale. And deliberately so: anything embodying the notion of
"complete" was at the higher (8-12) levels.

LH>Here is an interesting point. CP14.1 (& 14.2) of SpecGL don't
LH>mention the word "complete". Until it does, we should not assume
LH>"complete" at Level 5. "Complete" for the list of test assertions
LH>has the same problems of definition as "complete TS".

So "**the** list of testable assertions" (emphasis added) at Level 5
is really "**a** list of testable assertions"? That moves the chasm
to between 5 and 6, and I think it makes it large enough that (at
least conceptually) another Level 5.5 exists, where the set of test
assertions is intended to be complete. Or is the "complete test suite"
of Level 6 only complete with respect to the not-necessarily-complete
assertions of Level 5? If so, the verbiage of Level 7 should say
explicitly that additional contributions of test cases would continue
to be accepted. Pulling it all together, it means that the list of
test assertions can expand in maintenance mode, driven by combinations
of errata and contributed cases. I view this as a Good Thing. If we
need new forms of versioning to support it, the necessary mechanisms
should be instituted.
.................David Marston

Received on Tuesday, 14 January 2003 12:44:24 UTC