Spec Guideline: audience and expectations (re: issue #88)

Issue #88 on the issues list at
http://www.w3.org/QA/WG/qawg-issues-html
asks whether the proposed Spec Guidelines stray too far toward telling
editors what to do. Lofton already defended the current SpecGL thusly:

>Perhaps it is the language of the checkpoints' statements:  "Define
>the scope of the specification" sounds like a process imperative to
>the author. But its explanation clearly describes a condition on the
>result.

I think SpecGL is fulfilling its mission: one can evaluate a spec
according to the guidelines. The more checkpoints that are satisfied,
the more likely that implementers of products and authors of test cases
will achieve interoperability. There need to be checkpoints for levels,
deprecation, extensions, etc. because previously-published specs have
exhibited weaknesses in these areas. The guidelines represent a form
of coaching to spec editors only in the indirect sense that they show
how the spec will be evaluated. They are direct coaching to spec
evaluators, reminding them about details to be checked.

The audience of SpecGL would be spec evaluators and editors. The SpecGL
also affects the audience of the specs subject to evaluation. As I see
it, W3C specs are intended to define behavior for implementers and
testers, and even provide this value to implementers of tools that are
not among the classes of product that the spec claims to specify. I'll
re-use my XSLT example: officially, the XSLT spec only defines the
behavior of one kind of product, and XSLT processor, and it says so.
However, implementers of other products that create stylesheets want to
use the XSLT spec as a primary design guide. They rely on the processor
implementers to conform to the spec so that they in turn can sell their
tools as being able to generate stylesheets that any conforming XSLT
processor can run. Furthermore, I expect that I can learn to write XSLT
stylesheets from scratch, having learned how from any of the 20+ books
on the subject, and expect all conforming processors to run my
stylesheet. That means the book authors, trainers, contributors to the
on-line FAQ, and many others all worked off the common base provided by
the spec. This is the value proposition of open standards.

The spec represents a written agreement. ("Agreement" as both "consensus"
and "contract", though it's not a contract unto itself.) As a person who
gets frustrated when trying to use these specs, I want the QAWG to give
spec editors a set of goals, expressed as expectations or checkpoints on
the result. Some of these require the WG to make a decision that will be
expressed in the spec, because we readers/users/implementers need to know
their policy, and the spec is the formal way that we get it in writing.
That may constitute "telling the WG what to do", but only insofar as we
want their output to be useful and self-sufficient.
.................David Marston

Received on Wednesday, 2 October 2002 14:15:44 UTC