Re: [tag] About Prescription levels

[stephen.green@systml.co.uk]

Before I've considered this discussion I'd better at
least fulfill my AI on this and send an example of
my reasoning.

It does indeed seem that negating the predicate is in most cases
the same as negating the prescription level.

If I want to only allow prescription level values without 'Not'
(only 'permitted, mandatory, preferred') I can usually do so by
negating the predicate when the spec says MUST NOT. MAY NOT is
not a 2119 keyword so MAY seems to be regarded in 2119 (implicitly)
as near enough equivalent to MAY NOT and explicitly it compares
MAY to optional.

My argument is that to negate the predicate may sometimes
1. be tricky
2. not exactly match the spec in its logic when combined with positive PL

However I cannot find an example of this. The problem I found was in
Kevin's example in which he said something like:
"if A=B then C is optional"

Here
A=B could be a prerequisite;
C would obviously be a predicate
but what would the prescription level be?

The nearest of the three values 'permitted, mandatory, preferred'
seems to be 'permitted'. But my own logic doesn't feeel that this
is quite the same in meaning to 'optional'. To me a nearer fit is

prerequisite: A=B
predicate: not(C)
prescription level: permitted

I guess I have answered my own complaint here in that in this case
again the negating of the predicate with an overall 'not(...)'
fulfills the TA authoring requirement.

I still though think that not all predicates can be easily negated
so I'll resort to logic discussions I've seen (1) which claim that some
negations of negations are not the same as the equivalent without
either negation. In this case an already negative predicate that
needed to be negated again to match the PL would require care.

example

"It is not permitted to omit C but if A=B then omitting C is optional"

Here the negation of the predicate "C omitted" could be problematic
(in theory at least):

It might be like the following

prerequisite: A=B
predicate: not(not C)
prescription level: permitted

even if it is actually worded:

prerequisite: A=B
predicate: not(C omitted)
prescription level: permitted

I get the impression from the logic discussion (1) on double
negatives that this might not always mean what it seems
due in the main to the linguistic meaning of 'not(not a)'.
So here in theory I would perhaps think it better to say:

prerequisite: A=B
predicate: C omitted
prescription level: not mandatory

OK so it might be an edge case, I agree. But how would such an
edge case be foreseen when starting to write the TAs? That's
my argument as best I can put it.


  Ref (1) I've come across, for example, 'intuitionistic logic'
in which one can say that
"a is b" is not exactly equivalent to "not(a is not(b))" and I
think linguistically this is so too.

The question that is getting at me then is:
what is the difference between negating the predicate and
negating the prescription level? Is there one? I'm not
completely sure there is no difference. I know that isn't
exactly the same as saying "I'm sure there is a difference" :-)


-- 
Stephen D. Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice



Quoting "Durand, Jacques R." <JDurand@us.fujitsu.com>:

> So far we have the following values for the prescription level:
>
> - mandatory: cover statements that make use of keywords like : MUST ,
> SHALL, REQUIRED
> - preferred: cover statements that make use of keywords like : SHOULD ,
> RECOMMENDED
> - permitted: cover statements that make use of keywords like : OPTIONAL,
> MAY
>
> These values are an abstraction of these popular keywords. Their intent
> is to reflect the level to which the feature is prescribed by the
> specification. They are an indication for the test case writer of what
> the outcome means in terms of conformance.
>
> We need to decide of what to do with "negative statements" like MUST
> NOT,  SHOULD NOT, etc.
>
> So far, if keeping the above keywords, by default we have:
>
> MUST NOT,  SHALL NOT, (and MAY NOT?) --> mandatory, i.e. a predicate
> must be expressed so that it is "true" when the statement is fulfilled.
> E.g.: "the button MUST NOT be red" --> predicate = not ([button] is
> red).
> "Mandatory" prescription means generally that if the predicate is
> "false" the specification is violated.
>
> same for:
>
> SHOULD NOT, NOT RECOMMENDED --> preferred
>
> NOT REQUIRED --> permitted
>
> Now, if we want to have more freedom in expressing the TA predicate, and
> avoid having to use the negative form, as Stephen suggested we could say
> instead:
>
>  "the button MUST NOT be red"
> predicate = [button] is red.
> prescription = prohibited
>
> and:
>
>  "the button SHOULD NOT be purple"
> predicate = [button] is purple.
> prescription = discouraged (or "tolerated" ...)
>
> ===================================================================
> Questions are:
> ===================================================================
>
> -----  Question (1):  is there in some cases a difference worth of being
> reflected in the TA, between:
>
> predicate = [button] is red.
> prescription = prohibited
>
> and:
>
> predicate = not ([button] is red).
> prescription = mandatory
>
> I frankly would prefer not, but I may be wronged by a convincing
> example...
>
>
> ----- Question (2)
>
> Regardless of  answer  to (1) we have stated in the past that the
> predicate outcome interpretation actually is more subtle than "fulfills
> / violates", e.g.:
>
> (A)
> outcome"true" = spec requirement is fulfilled
> outcome"false" = spec requirement is violated
>
> should rather in many cases be understood as:
>
> (B)
> outcome"true" = spec requirement NOT violated so far
> outcome"false" = spec requirement is violated
>
> Question is:
>
> Should we do this distinction at TA level, or should we leave these
> subtleties to test cases?
> (In favor of testcase level: the TA only states a criterion of adherence
> to a spec statement, while the test case is the one making a more
> committing statement on a SUT.)
>
> If distinction at TA level, that means that "NOT violated so far" is not
> always same as "fulfilled". That means logically a 3rd value
> "undetermined" is needed. In that case we need a new interpretation
> element DIFFERENT from prescription, that says:
>
> outcome"true" = fulfilled / violated / undetermined
> outcome"false" = fulfilled / violated / undetermined
>
> or the like.
>
> NOTE: Even if ansering "no" to (2) we know that in some cases, some TA
> predicates cannot match exactly the specification requirement, for
> testability reasons (e.g. WS-I). A new "interpretation" element would
> allow describing such predicates that only allow partial tests against
> the normative statement.
>
>
>
>