- From: Lofton Henderson <lofton@rockynet.com>
- Date: Mon, 22 Oct 2001 08:05:11 -0600
- To: "Mark Skall" <mark.skall@nist.gov>
- Cc: www-qa@w3.org
At 05:45 PM 10/21/2001 -0400, Mark Skall wrote: [...] >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. I completely agree about "willy-nilly" -- we can't allow arbitrary functional changes under the guise of a defect correction. But I don't see leaving a mistake to stand -- especially if an open consensus process, which hopefully involves the implementation builders and application users, determines that it needs to be fixed. In my experience with graphics standards, there are lots of examples of defects where the statement is clear and unambiguous, but wrong. For example, ISO processed a (CGM) defect report in which there was an error (off by 1) in the count and indexing of weights and control points in a NURBS specification. It was clear and unambiguous. However, if you used it for computation, it would give a bad result. I think the best we can do to mitigate potential interoperability problems (because of products and applications vested in the error) is find and fix such errors fast. In the SVG WG, building the suites during the late phases of completion of the standardization process really helped a lot. -Lofton
Received on Monday, 22 October 2001 09:05:13 UTC