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

On Wed, 25 Jun 2003, Mark Skall wrote:

> At 02:11 PM 6/25/2003 -0600, Alex Rousskov wrote:
>
> >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
> >techniques).
>
> This is a useless requirement. Whether or not the requirements are
> identifiable is completely subjective and, (I might add) not
> testable.

I disagree. I believe that it is usually clear when requirements are
programmatically identifiable. For example, using all-caps for RFC
2119 keywords makes those keywords (and associated requirement
phrases) identifiable with a simple Perl script.

> We have some pretty good history that RFC 2119 makes requirements
> identifiable.

Yes, but only if capitalized or otherwise marked. It is not the RFC
that makes the requirements identifiable (because the RFC uses common
English words), it is the capitalization. RFC 2119 does not require
capitalization or special marking. Many RFCs use RFC 2119 keywords
without capitalization, leading to some non-requirements looking like
requirements (and, hence, violating the programmatically identifiable
principle).

> We need to use objective measures to ensure that requirements are
> identifiable, not subjective ones.

Yes, of course, to the extent possible. Apparently the definition of
an "objective measure" is subjective.

> > > 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.
>
>
> Huh?  We're talking about whether or not to mandate the keywords in
> RFC 2119, not whether to use MUSTs vs. SHOULDs.

Yes. I do not think my response implies anything else. Perhaps I
misinterpreted your "due to poor communication" phrase.

> Not mandating the keywords may (will) result in specs using
> alternative language.  Any alternative language is permissible.

Anything is permissible as long as the requirements are
programmatically identifiable. For example, it is OK to use no keywords
if the spec contains special visible marks that identify all
requirements (highlighting or whatever) and there is no plain-text
version of the spec (due to some other requirements).

> UAAG uses the imperative voice, but another spec may use a
> completely different set of keywords (have to, probably will, might,
> etc.)

Yes.

> Can we take the chance that their subjective interpretation that
> these new keywords make requirements identifiable result in other
> people thinking they're identifiable (again, a subjective decision)?
> I think not.

That is why I said programmatically identifiable or identifiable by a
deterministic algorithm. The rationale should add that the algorithm
should be of reasonable complexity and may encourage authors to
specify such an algorithm if it is not obvious/trivial.

Alex.

Received on Wednesday, 25 June 2003 16:46:44 UTC