On Sun, Jul 10, 2011 at 3:59 PM, Charles McCathieNevile <[email protected]> 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.
