Conformance claims, Priorities (was: Re: FYI : a new draft of "QA Framework - Specifications Guidelines" published)

A couple of comments about the conformance claims and priorities bits of 
the longer dialog, etc...

At 10:49 AM 9/5/02 -0600, you wrote:
>On 3 Sep 2002, Dominique [ISO-8859-1] Hazaël-Massieux wrote:
>
>[...]
> > > This is good but probably impractical. Even W3C "valid *ML" images do
> > > not (and cannot) satisfy this verbose format.

What do you mean by "'valid *ML' images" (esp. the word "images")?

I don't think that this is a serious issue for conformance claims about 
software (implementations).  The requirement in SpecGL is:

>         A well-formed conformance claim includes: date of the claim,
>         specification name, date and version, URI of the specification,
>         conformance level satisfied, and information about the subject
>         (that which is claiming conformance). Information about the
>         subject refers to information such as, the name of the software
>         or software component, version information, and operating
>         environment."

In fact, those details seem pretty routine and sensible for a software 
component (the reader of a claim really ought to be able to tell if it is 
V1.2 that passed the conformance test 3 years ago, and not the current 
v4.6, without having to do "20 questions" with some salesman).

So I gather that you're questioning the verbosity of the claim for a piece 
of content or other target objects?  It is probably worth discussing, as an 
issue.  Still, the following graphics example contains a lot of this 
information, and it could be viewed as the "conformance claim" from a 
particular WebCGM instance:

 >"ProfileId:WebCGM""ProfileEd:1.0""<
 >ColourClass:monochrome""Source:CGM<
 > Open/NIST""Date:20010404"<

It is missing a couple things like spec date and URI (which are implicit in 
ProfileId and ProfileEd), and the identification of the generating software 
components (that could have been included in the "Source" sub-string.)

> >
> > Being a priority 3 checkpoint, I don't think that's a big issue if it's
> > not practical.
>
>Great. I will ignore all priority 3 checkpoints from now on. Why waste
>time on something that is impractical?

As I suggested above, I think it is practical for software components.  We 
should look at other object categories (content pieces, etc).  It would be 
best if it's either practical, or "not applicable" for each subset of 
target objects.

For reference, we borrowed the priorities model from WAI.  For 
interoperability, testability, and the other goals of SpecGL, very roughly 
(in my own informal paraphrasing):

Priority 1:  essential/critical
Priority 2:  important/desirable
Priority 3:  beneficial/useful

>Are we trying to maximize the
>length of SpecGL?

IMO, we can probably condense the checkpoints somewhat, without even 
changing the scope of SpecGL (yes, I know -- we fail CK1.1 because SpecGL 
doesn't define its scope).

Whether we can condense radically is a major issue that you have raised 
(and that we have discussed in other thread, and that will be entered into 
the Issues List.)

>Seems to me that SpecGL violates its own recommendation for reducing
>variability by adding "optional" checkpoints with no practical value.

Highly subjective and arguable, whether "important/desirable" and 
"beneficial/useful" -- the characterizations for P2 and P3 checkpoints -- 
have "no practical value".

Regards,
-Lofton.