W3C home > Mailing lists > Public > www-qa-wg@w3.org > April 2003

Re: Proposed text for Section 3.1

From: <david_marston@us.ibm.com>
Date: Sun, 20 Apr 2003 11:42:27 -0400
To: www-qa-wg@w3.org
Message-ID: <OF36893A31.C382E5EA-ON85256D0E.005230FC-85256D0E.00565423@lotus.com>

LH>If you decide to [refer to all sentences that use RFC 2119 keywords],
LH>I wouldn't use "sentences", 
LH>which has been rightly criticized.  Use "statements", as you 
LH>currently use in one of your three new bullets. (And lets *not*
LH>argue about the boundaries of "statements".)
and later
LH>"Statements" -- can be a short phrase, a sentence, a collection of 
LH>sentences or phrases, etc.

I agree, too. In particular, the spec can use a sentence like the
following, which would be uncomfortably bulky if all the statements
were separated:
If the element following an X is an A, B, or C, the X must have an
@foo attribute set to the blah of that following element.
Additionally, sometimes the "statement" is actually a formula, as in
the explanation that substring() takes characters whose position in
the string is greater than [formula A] and less than [formula B].

It occurs to me that even if you label a whole section as normative,
sentences/statements only have normative power if they can be
construed to define behavior. This could be the obvious "a [CoP]
MUST do blah blah", a definition used normatively, a formula, or
something that doesn't look normative at first glance. Other remarks
in the section, such as an observation about the implications of the
blatantly-normative statements, might not be normative per se.

LH>(The definition/guidance of SHOULD is interesting -- it uses
LH>all sorts of superlative qualifiers that add up, "really, really, 
LH>recommended", as if that adds some testability to the untestable
LH>concept of conformance to SHOULD.)

Well, even if you can't test "conformance" to a SHOULD, you can
certainly test whether the product does what it "should" do. Example:
if you emit XML, by default it SHOULD be UTF-8 or UTF-16 encoded.
Invoke the product with no specified parameter for encoding, and see
what encoding you get in the emitted XML. Reporting the results is
valuable for decision-makers who may have embraced certain "should"
provisions in their plans. Therefore, QAWG should not disccourage
reporting (by magazines and websites, especially) of test results
for SHOULD provisions, and further should not discourage WGs from
placing tests of SHOULD provisions in their test materials, as long
as those tests are suitably labeled.
.................David Marston
Received on Sunday, 20 April 2003 11:43:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:30 UTC