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

At 04:03 PM 6/25/2003 -0600, Lofton Henderson wrote:
>At 02:53 PM 6/25/03 -0400, Mark Skall wrote:
>>I again vote for alternative 1.  I still have heard no satisfactory 
>>reasons not to require the keywords used (in caps).
>
>(Btw, the "in caps" is not presently part of the requirement of GL13.1, is 
>it?  And Pubrules says that caps should be mapped to lower-case italic or 
>something like that, "for readability", which issue we hassled with a bit 
>at f2f.)
>
>You may not consider them "satisfactory", but some possible reasons are:
>
>1.) We lack a convincing demonstration that all conformance contexts can 
>be handled with simple application of the RFC keywords alone.  UAWG 
>asserts this about UAAG10, for example.  (I am reporting this, without 
>taking a position on their correctness -- I haven't decided about that yet.)

I'm not sure that is what Ian was saying.  I think he was saying it was 
better or more convenient (his subjective opinion) to use other ways to 
enumerate requirements - not that it using the RFC keywords was insufficient.


>2.) Don't penalize (and antagonize) those who do have a good reason for a 
>different or a hybrid scheme, and who ensure that the scheme is well 
>defined, clear, and unambiguous (as required by Alt.2 or Alt.3).  As Alex 
>asserted, the "well-defined, clear, and unambiguous" (my words, not his) 
>are the key attributes, the RFC2119 keywords are a way to achieve them -- 
>the BEST way, we think (altho' some of us are not yet convinced that they 
>are universally applicable).


Don't penalize?  We're in the standards business.  I don't think that 
imposing a standard on spec authors is any more a penalty than imposing a 
standard on implementers.  There are very good reasons for standards.  In 
this case, the standard ensures clear enumeration of requirements.  Why are 
we afraid of asking our fellow spec writers to do as they say (use standards)?

>[Aside.  "well-defined, clear, unambiguous" -- okay, those words are 
>subjective.  I'm using them for the sake of discussion, and assume that we 
>can will up with something more precise and verifiable for SpecGL 
>text.  Maybe even along the lines of "programmatically verifiable".]
>
>3.) We have not yet explained in CP13.1 (but must do so) how its 
>simply-stated requirements apply to:
>3a.) Specs with bulk of specific requirements in formal language (like 
>DOM's IDL)
>3b.) Specs written with embedded Test Assertions.  (Remember when SpecGL 
>actually suggested or required that TAs be embedded?  Have we now come 
>full circle to say that embedded-TAs are prohibited as a form of 
>expression of requirements?)
>
>>They are an easy way to get the reader's attention that a requirement is 
>>present.
>
>But not the only way.  For example, imperative voice statement inside a 
>box with a green background, preceded with "ConfReq:" (and tagged with 
>markup).  That would get reader's attention pretty well.  (And would be 
>programmatically verifiable.)


You cannot programmatically verify that you are getting people's 
attention.  (Some of us have a very short attention span).  The whole 
purpose of using tried and true keywords is that we know it will get 
people's attention because  we've used them time and again.  There is now a 
conditioned reflex on the part of the reader to stop every time he or she 
sees a MUST and say "that's a requirement".

>>I don't buy "** Alt.2 or Alt.3 strongly encourage uniformity rather than 
>>forcing it, and that should suffice.".  Why should that suffice?
>
>"Would suffice" might have been a better way to state the position.
>
>Both Alt.2 and Alt.3 require a well-defined, clear, and unambiguous method 
>that is equivalent to RFC2119 (w.r.t. "identifiability").  Alt.3 in fact 
>requires a description of the correlation between the alternative method 
>and RFC keywords.
>
>IMO, the very fact that we present the upper-case RFC2119 keywords as the 
>BEST way to do it, and put the burden on the spec writers to completely 
>define and justify any deviation -- I think that will suffice to get 95% 
>(or some high percentage) of writers to use of RFC2119.

Again, I can't think of any justification that would obviate all the good 
we've done by imposing clear language.

>For the most part, spec writers are not devious and out to circumvent 
>well-thought-out guidelines.
>
>>Encouraging, but not mandating,
>
>...to be clear, Alt.2/3 mandate that any alternative method be "good", 
>with RFC2119 being by default the best.
>
>>this MAY result in non-compliance with specific requirements due to poor 
>>communication (didn't know it was a requirement).
>
>Alt.2 and Alt.3 both would require that any alternative to RFC2119 be 
>well-defined enough so that there is not ambiguity.  "Didn't know it was a 
>requirement", as an excuse, can be pretty much voided with some other 
>methods than upper-case RFC keywords.
>
>The reason I still hesitate about Alt.1 was well phrased by Alex.  With 
>Alt.2/3, "...we gain uniformity among most specifications and flexibility 
>for truly exceptional specifications."  Until I am completely convinced 
>that the set of "truly exceptional specs" is actually empty, I'm reluctant 
>to take the heavy-handed approach of mandating RFC2119 for everyone, no 
>exceptions.


What "heavy-handed" approach?  We have requirements all through SpecGL, 
OpsGL and TestGL.  Why is this one heavy-handed and not the others? IMHO, 
this one is much more important than many of the others.

>-Lofton.

****************************************************************
Mark Skall
Chief, Software Diagnostics and Conformance Testing Division
Information Technology Laboratory
National Institute of Standards and Technology (NIST)
100 Bureau Drive, Stop 8970
Gaithersburg, MD 20899-8970

Voice: 301-975-3262
Fax:   301-590-9174
Email: skall@nist.gov
****************************************************************

Received on Thursday, 26 June 2003 10:06:48 UTC