SpecET could help [was: Re: LC-67 leftover -- MUST use MUST?]

[...1 of 2 replies, on different aspects your message...]

You make an interesting observation (below) -- about my mixing of the roles 
of CP13.1, 13.2, and 13.4.

In fact, the whole normative package of a specification is a combination of 
specific and detailed normative text (e.g., describing the graphical effect 
of 100s of graphical elements and attributes), specific natural-language 
conformance requirements (e.g., SpecGL's own "Conformance Requirements"), 
formal language (e.g., DOM IDL), etc.

And there are lots of ways to put the package together, for example:

Alt.A:
---
[normative text:]  the graphical effect of text-on-path is:  1st character 
is positioned at X,Y, and subsequent characters are placed along the path 
according to ...blah...blah...[..for about 5 pages..]
--PLUS--
[conformance reqt:]  A Conforming SVG static viewer MUST render all 
graphical effects to an accuracy of 1 device pixel of the mathematically 
correct result.

versus...

Alt.B
---
[conformance requirement:]  Conforming SVG static viewers MUST put the 1st 
character at X,Y, and MUST put subsequent characters along the path 
according to ...blah...MUST...MUST...MUST...

For SVG, Alt.B is pretty unmanageable for many reasons (one of which:  SVG 
standardizes several Classes of Product, and each such 
conformance-requirement sentence would have to be replicated for each CoP, 
because what you say about a viewer is different from a generator is 
different from a transcoder/interpreter.)

For other standards (e.g., with only one CoP), two alternative approaches 
to balancing normative text and CRs might be more reasonably 
interchangeable.  I.e., there could be  (at least) a couple of equally good 
ways to write the spec (conformant to SpecGL).

Conclusion.  SpecET could help a lot by talking about these topics in some 
more detail -- how the various conformance-designating tools available to 
writers can be used effectively and in combination (and SpecGL-conformantly).

Regards,
-Lofton.

At 10:54 AM 6/26/03 -0600, Alex Rousskov wrote:

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

Received on Friday, 27 June 2003 12:05:33 UTC