- From: Lofton Henderson <lofton@rockynet.com>
- Date: Fri, 19 Oct 2001 09:53:27 -0600
- To: Mark Skall <mark.skall@nist.gov>, "Kirill Gavrylyuk" <kirillg@microsoft.com>, <David_Marston@lotus.com>, <www-qa@w3.org>
At 10:03 AM 10/19/01 -0400, Mark Skall wrote: >[...] >So the only confusion comes when something is ambiguous. In that case, I >would agree that the standards body (in this case W3C) should make the >interpretation. However, the tester should not test for something that is >not clear in the standard. The standard needs to be revised to reflect >the intent. Only after this occurs, can a test suite test for that >requirement. Until then, the test for that requirement should be >withdrawn. Standards developers must stand behind the wording in the standard. I agree. However, the length of W3C document cycle, by which corrections and clarifications actually get published, creates another problem. Some key point of a spec is ambiguous, so at best, implementors develop a formal consensus of "the right way", and at worst, they implement different interpretations. In the latter case, a legacy of problems becomes instantiated in products (and then ... see earlier "bugwards compatibility" thread). This suggests the utility of a "normative errata" mechanism. ISO has a formal "defects" process, for example. Defect corrections go through a formal review and resolution process, which is typically much shorter than document-release cycles. Once published, a Defect Resolution is considered to be part of the standard. -Lofton.
Received on Friday, 19 October 2001 11:51:43 UTC