W3C home > Mailing lists > Public > www-qa-wg@w3.org > April 2004

Re: QALites and relevant W3C documents

From: Lofton Henderson <lofton@rockynet.com>
Date: Fri, 09 Apr 2004 10:10:05 -0600
Message-Id: <>
To: Lynne Rosenthal <lynne.rosenthal@nist.gov>
Cc: www-qa-wg@w3.org

At 07:53 AM 4/9/2004 -0400, Lynne Rosenthal wrote:
>>Le 08 avr. 2004, à 00:45, Lynne Rosenthal a écrit :
>>>  1.  Pubsrules [2]:  Document versioning is tied to conformance, for 
>>> example “if a technical report with no changes that affect conformance 
>>> to a previous Rec, then the edition number is changed and no change to 
>>> revision no”. . Last year, Susan Leach asked us about this.
>>>  --relevant to SpecLite probably under Quality Control. We probably 
>>> should mention something, but not go into details
>>I'm not sure I understood the requirements or the question, would you 
>>mind to give an example? Sorry.
>I was just pointing out that PubsRules uses conformance (whether changes 
>affect conformance) to determine if something is a new version or a new 
>edition.  SpecLite doesn't address this and shouldn't.

Agreed.  Pubrules gives rules for naming of specs, i.e., whether something 
should be called, for example, SVG 1.2 (minor version) or SVG 2.0 (major 

>However, since there is a relationship between new version/edition and 
>conformance, perhaps SpecLite should mention somehing - possibly as an 
>example - of what?  I'm not sure.  Maybe, an this is an example of how 
>conformance is used to determine things other than an implementation 
>conforms to a spec. or implements a function correctly.   So.  My question 
>to the group - does this make sense?  Is it something we should mention in 

I think SpecLite should mention what Pubrules does and point to it -- i.e. 
"Pubrules gives @@spec naming rules@@ for subsequent specification versions 
depending on the relative conformance characteristics of the two 
versions".  Otherwise (SpecLite could say), the conformance relationship of 
subsequent versions is out of scope for SpecLite, except in the case that a 
later version deprecates features of an earlier version.

This could, for example, be handled in the scope/out-of-scope section (or 
elsewhere, if it fits better elsewhere).

Received on Friday, 9 April 2004 12:11:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:36 UTC