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

At 10:32 PM 6/25/03 -0600, Alex Rousskov wrote:
>On Wed, 25 Jun 2003, Lofton Henderson wrote:
>
> > 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)
>
>When I use a BNF or a similar formal language in a spec, I say
>something like
>
>         "The BNF above defines syntactically valid messages.
>         An implementation MUST forward any syntactically
>         valid message."
>
>This way, it is always possible to tie/merge a MUST with formal
>language rules (BNF). Is that something you are after in 3a?

Yes, that's the idea.

One of the current problems with CP13.1 is that it is way too vague.  Even 
for someone acting in good faith will have difficulty determining what it 
requires in various conformance contexts.

For example, one could have this single line in the spec, "Conforming 
implementations MUST do all of the requirements of this 
specification."  The "requirements" might be simple descriptive lines of 
text scattered throughout the spec (e.g., describing the graphical effect 
of a given graphical element).  Does this conform to CP13.1?

It seems that this particular vagueness has to do with the granularity of 
the use of MUST versus the granularity of the actual conformance 
requirements (in the above example case, statements of correct graphical 
interpretation of hundreds of elements and attributes).

Another example, look at this excerpt from SVG Appendix G (normative 
conformance clause):

>This appendix is normative.
>
>G.2 Conforming SVG Document Fragments
>
>An SVG document fragment is a Conforming SVG Document Fragment if it 
>adheres to the
>specification described in this document (Scalable Vector Graphics (SVG) 
>Specification)
>including SVG's DTD (see Document Type Definition) and also:
>
>* (relative to XML) is well-formed.
>* if all non-SVG namespace elements and attributes and all xmlns 
>attributes which
>refer to non-SVG namespaces other than the XLink namespace are removed from
>the given document, and if an appropriate XML declaration (i.e., 
><?xml...?>) is
>* [...snip a lot more bullets...]
>
>The SVG language or these conformance criteria provide no designated size 
>limits on any
>aspect of SVG content. There are no maximum values on the number of 
>elements, the
>amount of character data, or the number of characters in attribute values.

Does this violate CP13.1 as currently written?  (For context, SVG11 *does* 
use RFC2119 keywords elsewhere, in lower-case [which LC does conform to 
CP13.1]).

Conclusion.  However we resolve this current issue, we need a lot more 
description in either SpecGL, or SpecET, or both.


> > 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?)
>
>The Glossary definition of TA is "A set of premises that are known to
>be true by definition in the spec". In my interpretation it simply
>means "a definition" (if somebody could point out the difference,
>please do).  Definitions are not requirements, but virtually all
>requirements use them. The BNF example above illustrates how a MUST
>requirement uses a definition of a valid message. Did I misunderstand
>the problem of 3b?

The QA Glossary is several months out of date.  The pre-f2f accepted 
definition, which was supposed to have been put into the QA Glossary, is 
the verbiage in GL14 [1].  This wording was fine-tuned at the Crete f2f, 
but I don't have the specifics handy now.

Let me use a simple example:

Conformance Requirement:  "the specification MUST use RFC 2119 keywords to 
denote whether requirements are mandatory, optional, or suggested."

Test Assertion:  "The specification uses RFC 2119 keywords to denote 
whether requirements are mandatory, optional, or suggested."

(Do I have this right, Mark?)

At one point, we thought that Test Assertions might be embedded in the 
spec's text to express its requirements.  I.e., instead of having the CR in 
the text, one might have the TA in the text (and in fact tag it with 
markup).  We no longer require that.  But I'm curious to know whether a 
spec written using TAs to express the testable requirements would fail 
CP13.1 (under alt.1)?

-Lofton.

[1] http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/#Gd-include-assertions