W3C home > Mailing lists > Public > www-qa@w3.org > October 2001

RE: [www-qa] Re: Conformance and Implementations

From: Mark Skall <mark.skall@nist.gov>
Date: Sun, 21 Oct 2001 17:45:02 -0400
Message-Id: <5.0.0.25.2.20011021172206.00a735b0@mailserver.nist.gov>
To: "Lofton Henderson" <lofton@rockynet.com>, David_Marston@lotus.com
Cc: www-qa@w3.org

>>
>>Yes, I think you're describing the errata process. It appears that
>>Mark Skall is raising a caution that an erratum that reverses the
>>meaning of a spec is a Bad Thing. If I am interpreting his reply
>>correctly, the WG can know "what it meant" (design rationale) and can
>>use the errata process to fill in places where their rationale was
>>under-expressed, but if the spec said something contrary to what the
>>WG meant, then they (and we) are stuck with what it says.
>
>I'm not sure if I interpret it (Mark's point) that way.  If that's how he 
>meant it, then I disagree.


Ok, let me interpret my own point.  It' really pretty simple.  All I am 
saying is that you write tests to test exactly what is required by the spec 
(that is the bible) - no more and no less. If the spec is clear, no 
interpretation is needed.  If the spec is ambiguous, someone needs to 
interpret and change the spec to make it unambiguous.  No test should be 
used until the spec (or some other normative reference like an errata)  is 
changed to remove the ambiguity.  If and when the spec changes (and only 
then), new tests can be developed to test the new requirements, if 
resources permit. The hard part is interpreting an ambiguous 
requirement.  Writing the tests are straightforward.  You write tests for 
normative, documented requirements.

I also believe that a requirement in the spec should only be reworded if it 
is ambiguous. A clear, non-ambiguous requirement should not be changed. 
Implementers will have already implemented the requirement and applications 
will have used these implementations. Interoperability would go out the 
window if we, willy-nilly, started changing requirements. 
Received on Sunday, 21 October 2001 17:45:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:28 UTC