- From: Lofton Henderson <lofton@rockynet.com>
- Date: Wed, 25 Jun 2003 16:03:42 -0600
- To: Mark Skall <mark.skall@nist.gov>
- Cc: www-qa@w3.org
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