- 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