Re: Testable assertion tagging for W3C specifications

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. Or, at least, if all such
perfect schemes had already been invented. On all other cases, the
time was not wasted, but spent, possibly doing useful work.

> Right now, I'm inventing some new markup for the Framework
> documents -- fun but time-consuming.  It would be nice to have a
> collection of techniques for potential adoption (and if none of
> them fit my requirements, *then* some invention is in order.)
> 
> Beyond saving re-invention, I don't have a problem with diversity
> per se.  If each WGs solutions satisfy quality requirements that
> we are trying to articulate at a high level (e.g., "Traceability",
> of a test case back to its underlying test assertions and
> supporting statements in the spec), then that seems like the first
> priority requirement.  As with WAI, I anticipate some diversity of
> ways to satisfy a checkpoint.

I believe we are in agreement here. Working groups would clearly
benefit from a well-documented and supported set of markup languages
to write their specs. If currently available languages are not
sufficient, and if W3C members allocate resources for writing new
"markup for writing standards" languages, nobody should object to
writing those languages.

My only recommendation is that W3C does not _mandate_ a complex
one-size-fits-all language based on current requirements. As you said,
W3C can and should mandate high-level "quality" properties (where such
properties can be identified and formulated in a non-discriminatory
way).

> However, where uniformity might pay off is further downstream in
> the QAWG work.  We're just starting to investigate the question,
> to what degree can we create and offer a collection of common
> formats, tools, templates, etc, for the building, management, and
> maintenance of test suites (so that each WG doesn't have to invent
> all of this stuff also)?  We are unsure of the answer, but this
> seems true:  uniformity (of specs, etc) will help, diversity will
> hurt.

Uniformity will help QAWG. Diversity will hurt QAWG. QAWG work is very
important but nevertheless _secondary_ to the work of other groups.
Other working groups invent and produce; QAWG just helps them along,
on a meta-level. QAWG can help by offering a "QA Collection". QAWG
should not restrict WG group choice to that Collection or to a
specific item in that Collection.

In other words, QAWG should tell other WGs:

	"If you use our tools/formats, here are the benefits and
	drawbacks you get. If you do not use our tools/formats,
	you are on your own, but let us know if your custom
	tools/formats should be added to QA Collection. Whatever
	you use, here are the meta-level rules you must obey."

Re-invention is bad. Re-invention can be reduced by documenting and
supporting already invented. Re-invention is better than prohibition
on invention (no-invention).

Alex.

Received on Tuesday, 28 May 2002 17:47:32 UTC