- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Sun, 10 Jul 2011 16:34:59 -0400
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: Rich Tibbett <richt@opera.com>, public-webapps <public-webapps@w3.org>
On Sun, Jul 10, 2011 at 3:59 PM, Charles McCathieNevile <chaals@opera.com> wrote: > Privacy and security restrictions leap to mind. There are things that really > are "should" requirements because there are valid use cases for not applying > them, and no reason to break those cases by making the requirement a "must". > In the normal case where they are applied you want to be able to test. Were you thinking of specific examples? I can't think of any offhand. > But the difference between "should" and "must" is already two sets of > conformance profiles (or whatever you want to call it), where one applies > always and the other applies unless there's a reason not to do the thing > that is assumed to be normal. The difference is that if you have "must" requirements that are specific to a single conformance class, you can write a test suite and expect every implementation in that class to pass it. For "should" requirements, you're saying it's okay to violate it, so test suites don't make a lot of sense.
Received on Sunday, 10 July 2011 20:35:54 UTC