- From: Lofton Henderson <lofton@rockynet.com>
- Date: Fri, 20 Sep 2002 13:21:13 -0600
- To: Alex Rousskov <rousskov@measurement-factory.com>
- Cc: www-qa@w3.org
- Message-Id: <5.1.0.14.2.20020920122628.03abdec0@rockynet.com>
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.
Received on Friday, 20 September 2002 15:20:09 UTC