- From: Mark Skall <mark.skall@nist.gov>
- Date: Wed, 25 Jun 2003 14:53:37 -0400
- To: Lofton Henderson <lofton@rockynet.com>, www-qa@w3.org
I again vote for alternative 1. 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. 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? Mark At 09:54 AM 6/25/2003 -0600, Lofton Henderson wrote: >This a leftover issue about test assertions and conformance >requirements. Let's have some mail discussion so that the SpecGL editors >can close it at next telecon. > >The first part of LC-67 [1] asks, "must all [conformance requirements] use >RFC2119 keywords?" > >[Note. In that paraphrasing, I substituted "conformance requirements" for >the originator's "testable statements and or test assertions", in line >with our clarification of terminology at the Crete face-to-face. By our >definition of test assertions, they inherently do not use the RFC2119 >keywords.] > >This was originally addressed, including a proposed resolution, in email >[2]. It was further discussed a bit at the Crete f2f without resolution [3]. > >Alternatives: >----- > >At the face-to-face, these alternatives seemed most popular: > >Alt.1: yes, per the current wording of the (priority 1) SpecGL CP13.1 [4] >and its rationale, all specifications must use the RFC2119 keywords [in >the statement of conformance requirements]. > >Alt.2: no, the RFC2119 keywords are the recommended and preferred way, >but other language is permitted (e.g., marked-up imperative voice >statements), as long as the spec unambiguously defines what are its >conformance requirements and how are they identified in the text. > >Alt.3: as Alt.3, but the spec must particularly define the correspondence >between its normative language scheme and the RFC2119 keywords. > >Discussion >----- > >Among the points made in f2f discussion: > >** Alt.2 or Alt.3 strongly encourage uniformity rather than forcing it, >and that should suffice. > >** Contra. Uniformity should be mandated for all new specifications (and >don't be too concerned with SpecGL conformance for existing specifications.) > >** Observation. UAAG10 is almost AAA-conformant, but will fail CP13.1 [4] >as written and so would not be A-conformant (UAAG10 fits Alt.3 pretty >well). Some thought that it would hurt SpecGL credibility, if it fails a >spec that is generally considered pretty good. > >** Note. QAWG asked UAWG about its rationale for not purely following >RFC2119, and UAWG replied -- see [5]. > >** Difficulty with CP13.1 as written: what about specs in formal language >like DOM, or specs that use embedded test assertions for normative text, >instead of more general conformance requirements? (Note. Are there any >good examples of the latter?) > >** Pro Alt.1: per the rationale at [4], this forces spec writers to >unambiguously indicate what are the conformance requirements, and makes it >very easy for implementers, test builders, etc to find the conformance >requirements. > >Discussion and/or proposals? > >Regards, >-Lofton. > >[1] http://www.w3.org/QA/WG/lc-issues#x67 >[2] http://lists.w3.org/Archives/Public/www-qa/2003Jun/0013.html >[3] http://lists.w3.org/Archives/Public/www-qa-wg/2003Jun/0041.html >[4] http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/#Ck-use-keywords >[5] http://lists.w3.org/Archives/Public/www-qa-wg/2003Jun/0039.html **************************************************************** 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 Wednesday, 25 June 2003 14:54:13 UTC