- From: Mark Skall <mark.skall@nist.gov>
- Date: Sun, 21 Oct 2001 17:45:02 -0400
- 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