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

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

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

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


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

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.

-Lofton.

Received on Wednesday, 25 June 2003 18:03:43 UTC