- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Tue, 1 Jul 2003 10:37:13 -0600 (MDT)
- To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- cc: www-qa@w3.org, connolly@w3.org
On Tue, 1 Jul 2003, Jeremy Carroll wrote:
> > criteria; I can easily render them with an "or else" part:
> >
> > 2 + 2 MUST be 4 or else the summator module violates
> > rule X.Y of RFC 1234 and MUST NOT be auto-loaded.
> >
> > Every attribute value in an XML document MUST be quoted
> > or else the document is invalid. See section X.Y for
> > requirements on handling invalid XML documents.
> >
>
> No ...
>
> The summator MUST give the answer 4 in response to the question 2+2.
The correct (or "better") wording would depend on the context. For
example, the spec may define a "+" operation as a part of some
language or whatever, making my original wording perfectly legal and
even better than "the question 2+2".
> Try
>
> 2 + 2 MUST be 3 or else the summator module violates
> rule X.Y of RFC 1234 and MUST NOT be auto-loaded.
>
> In your text no possible summator even one that gives a random
> output to any input can be violation because 2+2 IS 4.
See above. Also, keep in mind that 2+2 is 4 only in some environments.
2+2 is actually 11 in base-3 logic. These are just abstract
statements/requirements we are manipulating here! There is no context
(there will be in the actual spec). Imagine a summator that has "base"
as a configuration option...
> MUST is for agents.
and other similarly semi-defined things, as appropriate according to
author's judgment.
Alex.
P.S. I doubt I would ever write a "2+2 MUST be X" statement in a spec.
I am using provided examples simply to illustrate the point that
it is impossible to clearly specify when to use MUSTs and when
to use BEs. Note that the original question of this thread is
somewhat different: whether anything but MUSTs can be used in
a compliant specification to form CRs?
Received on Tuesday, 1 July 2003 12:37:19 UTC