- From: David Marston/Cambridge/IBM <david_marston@us.ibm.com>
- Date: Wed, 2 Oct 2002 14:14:48 -0400
- To: www-qa@w3.org
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