Re: LC-67 leftover -- MUST use MUST

On Tue, 2003-07-01 at 10:09, Alex Rousskov wrote:
> On Tue, 1 Jul 2003, Jeremy Carroll wrote:
> 
> > I note that I find Connolly's
> > http://www.w3.org/2001/01/mp23
> > "must is for agents"
> > compelling.
> 
> The above URL says:
> 
> 	I try to use the word MUST to constrain agents in processes,
> 	not to just make declarative statements; i.e. I think it's a
> 	misuse of RFC2119 to say things like "2 + 2 MUST be 4" or
> 	"every attribute value in an XML document MUST be quoted."
> 	Better to just say "2 + 2 is 4"  and "every attribute value in
> 	an XML document is quoted." MUST should be reserved for cases
> 	like "you MUST be 4 feet tall to ride the rollercoaster." i.e.
> 	every MUST has an implicit "or else."
> 
> It would be nice if we could somehow distinguish statements that are
> (or should be) "declarative" in nature from statements that (should)
> constrain agents behavior. To me, the distinction is very unclear.

Your examples below suggest to me that it's actually pretty
clear to you...

> Moreover, the above examples seem to contradict the proposed "or else"
> 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.

Note that you introduced a "summartor module" and (implicitly)
a module loader into the discussion in order to use MUST NOT.

If you were writing a specification of a summator module
agent or a module loader agent, some MUSTs might be appropriate.

But note that what you actually write above is tantamount
to
	no summator module violates rule X.Y.

since it is the case that 2 + 2 is 4.

> 	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.

Again, you have introduced an implicit agent into the
discussion in order to introduce the MUST. Section X.Y
is, apparently, a specification of an agent that handles
documents, including invalid documents.

Even so, the document would be clearer if all the MUSTs
were in section X.Y, with reference to the term 'valid
XML document', and in this section where we're specifying
valid XML documents, we just said "Every
attribute value in a [valid] XML document is quoted."


> And, vice versa, the rollercoaster example can be rephrased as
> 
> 	Rollercoaster riders are 4 feet tall

But if a kid under 4 feet got on the roller coaster, that would
just become false. It wouldn't say whose fault it is that
it became false. The reason we use MUST for agents to make
it clear whose fault it is when protocols are violated.


> Overall, it seems to me that the whole issue of "correct" RFC 2119
> keyword usage is moot. There is no a single correct way and it is not
> important to have one.

I disagree. There are better ways and worse ways to use RFC2119.


>  Related important matters are:
> 	- spec MUST define what Compliance Requirement (CR) is
> 	  (i.e., how to isolate CRs from the rest of the spec)
> 	- spec MUST define Compliance in terms of CRs
> 	  (i.e., given a spec subject, how to determine compliance)
> 	- spec MUST define Scope
> 	  (i.e., what spec subjects are)
> 
> Personally, I use a mixture of definitions (X is Y) and behavioral
> requirements (X MUST Y) in specs, but I am not sure I can define
> exactly when I use one versus the other. I simply use whatever seems
> natural to me in a given context. This subjectivity is not a problem,
> IMO, as long as CRs, Compliance, and Scope are defined by the spec.
> 
> Alex.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Tuesday, 1 July 2003 13:59:09 UTC