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

Re: LC-67 leftover -- MUST use MUST?

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Wed, 25 Jun 2003 14:11:10 -0600 (MDT)
To: Mark Skall <mark.skall@nist.gov>
cc: Lofton Henderson <lofton@rockynet.com>, www-qa@w3.org
Message-ID: <Pine.BSF.4.53.0306251400130.5542@measurement-factory.com>

On Wed, 25 Jun 2003, Mark Skall wrote:

> I still have heard no satisfactory reasons not to require the
> keywords used (in caps).  They are an easy way to get the reader's
> attention that a requirement is present.

My understanding is that W3C considers UAAG an example where RFC 2119
keywords are not good enough. See authors comments quoted by Lofton.
>[5] http://lists.w3.org/Archives/Public/www-qa-wg/2003Jun/0039.html

Also, please do not mix the question of whether to use RFC 2119
keywords with a question whether keywords must be in caps. I disagree
that specs MUST use RFC 2119 (I think they SHOULD). I agree that
requirements MUST be programmatically identifiable (without AI

> I don't buy "** Alt.2 or Alt.3 strongly encourage uniformity rather
> than forcing it, and that should suffice.".  Why should that
> suffice?  Encouraging, but not mandating, this MAY result in
> non-compliance with specific requirements due to poor communication
> (didn't know it was a requirement).  What can be gained by this?

This is a strange argument. If we accept "didn't know it was a
requirement" as an excuse, there is no reason to write SpecGL at all.
SHOULD and MUST have about the same visibility and about the same
probability of being unknown due to poor communication. By making this
requirement a SHOULD we gain uniformity among most specifications and
flexibility for truly exceptional specifications.


                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance
Received on Wednesday, 25 June 2003 16:11:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:32 UTC