Re: Testable assertion tagging for W3C specifications

At 03:47 PM 5/28/02 -0600, Alex Rousskov wrote:
>On Tue, 28 May 2002, Lofton Henderson wrote:
>
> > Having a standard cuts both ways -- it is one more thing to have
> > spend time picking up and applying, but on the other hand it saves
> > the effort of constantly re-inventing new ways to do common
> > things.  At a recent tech plenary, someone asked, "How may of you
> > put together and maintain your own issues-tracking schemes?"
> > Lots of wasted time in the forest of hands that went up!
>
>That time was indeed "wasted" if there was One True Issues-tracking
>Scheme that was perfect for everybody.

To be accurate, *some* of the time was wasted, if 10*N people effectively 
spent their time re-inventing the same N variants (let's not quibble about 
the number "10" -- it is purely for illustration).  I was lucky to stumble 
upon a DTD that, upon examination, did most of what we (QAWG) wanted, and 
looked a lot like what I probably would have invented.  So we were able to 
borrow (and customize it a little bit) with small effort.  The point 
is:  an organized collection of a few issues tracking schemes would save a 
*lot*  of effort.  I don't mean to imply that there is One True 
issue-tracking scheme.

Now apply the analogy to specification markup grammars, and even test 
materials (tools, harness designs, templates, etc).

>[...]
>My only recommendation is that W3C does not _mandate_ a complex
>one-size-fits-all language based on current requirements.

IMO, this would be hard, if not impossible, to do.  On the other hand, I 
think it *is* possible to offer a relatively small set of language options 
-- either simple ones, or ones ranging from simple to complex -- that meet 
the needs of many (most?).

>[...]
>Uniformity will help QAWG. Diversity will hurt QAWG.

Correction, uniformity makes it easier for QAWG to offer collections of 
useful tools and services, diversity makes it more difficult.

>QAWG work is very
>important but nevertheless _secondary_ to the work of other groups.
>Other working groups invent and produce;

Are you confusing "QAWG work" with "quality practices" here?  The latter is 
the purview and responsibility of the WGs, and "QAWG work" is entirely 
aimed at facilitating that.  It is unfortunate that, in some cases, 
"quality practices" (test suites, well-structured and testable 
specifications, etc) are indeed considered secondary to "invent and 
produce".  Fortunately, it is not always so.

>QAWG just helps them along,
>on a meta-level. QAWG can help by offering a "QA Collection".

That is certainly within QAWG scope.

>QAWG
>should not restrict WG group choice to that Collection or to a
>specific item in that Collection.

QAWG has no authority to restrict, require, impose, etc.  We produce 
Framework documents, which contain guidelines and checkpoints derived from 
past good practice.  Granted, a WG can assess its compliance with a 
Guideline document.  But the assessment is for its use and benefit, and has 
no consequence or enforcement outside of the WG.  We will, hopefully, 
produce collections of useful tools.  These aim to assist and facilitate 
the WGs.  This is all spelled out in "Framework: Introduction"  [1].

>[...]
>Re-invention is bad. Re-invention can be reduced by documenting and
>supporting already invented.

No argument here.

-Lofton.

[1] http://www.w3.org/TR/qaframe-intro/

Received on Wednesday, 29 May 2002 10:09:11 UTC