- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Thu, 26 Jun 2003 09:33:49 -0600 (MDT)
- To: Mark Skall <mark.skall@nist.gov>
- cc: Lofton Henderson <lofton@rockynet.com>, www-qa@w3.org
On Thu, 26 Jun 2003, Mark Skall wrote: > I'm sorry but it's not good enough to be "usually clear". One > "non-clear" spec could do an awful lot of damage. If we can't > guarantee clearness (which we can't) why not use RFC 2119 keywords > which we know are clear? To me this is an obvious decision. In one > case - no problems; in the other case - potential problems. RFC 2119 is not perfect or perfectly clear. There are no perfect RFCs. The best we can do is to strike a balance between uniformity of rigid imperfection and useful exceptions. Nothing here is or can be completely formalized or perfected because we use informal languages and work with informal concepts. > Again, what are obvious special marks to you might not be to me. I > agree that there are some cases when we would all agree that the > requirements are clear, but we certainly cannot count on getting > these. What we will probably get are at least some cases where some > people think the requirements are clear and others misinterpret > them. True. IMO, this is an acceptable risk worth the gain. The gain, in this case, is to allow innovation and decent to sneak in (when the authors are convinced their requirement marking/defining ways are better). While I like formalism, I also accept the reality (informal language used to define informal concepts). Your preference is to be 100% safe (a MUST) and prohibit innovation/decent to avoid risks. My preference is to be 95% safe (a SHOULD) and allow some innovation/decent, with known risks. Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance
Received on Thursday, 26 June 2003 11:33:57 UTC