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

On Thu, 26 Jun 2003, Lofton Henderson wrote:

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

I disagree. You seem to require CP13.1 to do what other CP do; see
below.

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

Yes, but not to CP13.2 and not to CP13.4.

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

I think CP13.2 and not to CP13.4 cover that, don't they?

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

No, because "(relative to XML) is well-formed" does not use RFC2119
keywords. It should say "MUST be well-formed" or "SHOULD be
well-formed" to conform.

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

I am lost here. I do not know how to interpret "a spec written using
TAs to express the testable requirements". If TAa are CRs then they
would fail CP13.1 unless they use RFC 2119 keywords. If TAs are not
CRs but something that compliments CRs than they are not subject to
CP13.1 (only CRs are the subject).

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

Received on Thursday, 26 June 2003 12:54:45 UTC