Re: [tag] About Prescription levels

[stephen.green@systml.co.uk]

Proposal:

In regard to my first issue - mapping of MAY to
permitted being not quite right (need to say:
'predicate x permitted' And 'predicate Not(x)
permitted'), I'd propose (* If we are still not
including negated prescription levels *) we
replace 'permitted' with 'optional'. Then, for
'MAY x' in spec we only need 'x', 'optional' in
test assertion.

Then we have all one-to-one mappings for all the
RFC 2119 keywords in the Spec to the Prescription
Level and Predicate in the Test Assertions:

For predicate x
  1) MUST x       --  mandatory   x
  2) MUST NOT x   --  mandatory   Not(x)
  3) SHOULD x     --  preferred   x
  4) SHOULD NOT x --  preferred   Not(x)
  5) MAY x        --  optional    x

Best regards
-- 
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 stephen.green@systml.co.uk:

> OK, I buy it that for MUST and for MUST NOT the use
> of 'mandatory' as a PL with negation of the predicate
> will work for logically stated (more formal logic,
> less linguistics) predicates.
>
> Also I've rationalized the RFC 2119 equivalents in our
> TA model but I still have four issues.
>
> Before the first issue, here is how I map RFC keywords
>
> For predicate x
> 1) MUST x       --  mandatory   x
> 2) MUST NOT x   --  mandatory   Not(x)
> 3) SHOULD x     --  preferred   x
> 4) SHOULD NOT x --  preferred   Not(x)
>
> Then I have a slight issue with the last one
>
> 5) MAY (= 'optional')
> This has two TAs for each normative statement with a MAY
>                 --  permitted  x
> and             --  permitted  Not(x)
>
> So that's one issue - maybe educational
>
> The other three are about how the negation is done.
> If x is a logical expression then simply stating it as Not(x) may
> suffice without creating ambiguity, I agree. But what if x is
> a lengthy piece of prose and the use case is that minimal
> rewriting is to be undertaken so as to avoid change/loss of meaning.
> Maybe there just needs to be something in the model to add the
> negation to the predicate outside of the predicate itself:
>
> Choice of:
> Predicate: x
> or
> Predicate NOT: x
>
> Then the third issue is how to negate a prerequisite when the
> requirement is that for the TA to be valid the prerequisite TA
> has to NOT be valid (False or even False/Undefined or even just
> Undefined perhaps).
>
>
> Finally, what about the use case we agreed to with the implicit
> predicate. How would there be any negation in that case to allow
> for MUST NOT, SHOULD NOT and MAY?
>
> -- 
> 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.
>>
>>
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php