RE: [tag] ambiguity in current TAG draft

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

Stephen: <JD>

-----Original Message-----
From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
Sent: Wednesday, December 03, 2008 12:20 AM
To: Durand, Jacques R.
Cc: tag@lists.oasis-open.org
Subject: Re: [tag] ambiguity in current TAG draft

It would work and personally I'm ready to agree with it. I think we need to say more about including the 'not' in the predicate, even if it appears, in the normative source, as part of what we call the Prescription Level:

So 'the widget battery MUST NOT be larger than the widget'
becomes

Normative Source: the widget battery MUST NOT be larger than the widget
Target: the widget battery
Predicate: [the widget battery] is not larger than the widget Prescription Level: mandatory

The predicate is negated instead of the prescription level, even though in the normative source it is the prescription level which is negated.

<JD> In order to avoid confusion (and the possible double-negation of a MUST NOT requirement by a negative predicate + negative PL) should we make clearer that the PL qualifies the Predicate, and is NOT a mere reflection of the requirement keyword in the spec. In other words, the combination Predicate+PL must reflect the source requirement - i.e. both a testable assertion and how imperative is it that it be "true" - or "false", in order to indicate fulfillment of the spec.

Ideally I would want to add that this is only a recommendation: There might be occasions when there is good reason that the negative RFC
2112 keywords MUST NOT or SHOULD NOT are used and that it might therefore in such cases be better to use negated prescription levels values in the test assertions. In such cases the negation from the normative source RFC 2112 keywords should not be included in the predicate. I appreciate this is extra detail which might be too much for the guidelines as we have them (perhaps postpone for future advanced treatment of TAs); plus it might be a while before I can come up with an example or clear use case of where an negative RFC 2112 keyword is to be prefered over the combination of a positive one and a negation outside of the keyword ('x MUST NOT y' prefered to 'x MUST not y').

2008/12/3 Durand, Jacques R. <JDurand@us.fujitsu.com>:
> Avoiding the need to change the predicate seems to serve a practical
> purpose
> - e.g. some test case has been written for the original predicate, and
> one wants to be able to reuse as much as possible from previous test cases.
> Although that could be seen as beyond the concerns of this guideline
> doc, here is what I propose:
>
> - we RECOMMEND that users stick with the three "positive" PL values:
> mandatory / preferred / permitted, even for Tas that refer to negative
> statements (MUST NOT..). That means we recommend that the predicate =
> true when the target fulfills the spec requirement.
>
> - In some cases, e.g. the handling of new conformance clauses, one may
> want to derive new Tas that are as close as possible to previous ones,
> e.g. reuse same predicate. In that case, the PL MAY take additional
> "negative" values, like "not permitted" , "not preferred".
>
> Would that work?
>
> So to illustrate:
>
> Main spec:
>
> TA: main_123
> norm source: req 123
> Predicate: A=B
> PL: Permitted
>
> In Conformance Clause XYZ, A=B is no longer permitted: both the
> following are OK
>
> (option 1)
> TA: XYZ_123
> norm source: req 123 revisited by conf clause XYZ
> Predicate: A=B
> PL: Not-Permitted
>
> (option 2)
> TA: XYZ_123
> norm source: req 123 revisited by conf clause XYZ
> Predicate: not(A=B)
> PL: Mandatory
>
>
>
> Jacques
>
>
>
> -----Original Message-----
> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com ] On
> Behalf Of Stephen Green
> Sent: Friday, November 28, 2008 6:08 AM
> To: Durand, Jacques R.
> Cc: tag@lists.oasis-open.org
> Subject: Re: [tag] ambiguity in current TAG draft
>
> Another reason for *some* cases using negative prescription level values:
>
> A conformance profile restricting a previous conformance profile will
> likely wish to restrict some of the the 'Permitted' values of
> presciption levels to something equivalent to MUST NOT - avoiding the
> need to change the predicate from A=B to A!=B. Having the ability to
> use 'Not Permitted' would be helpful.
>
> 2008/11/27 Stephen Green <stephen.green@documentengineeringservices.com>:
>> I agree the last example does not *need* a negative prescription
>> level
>>
>>>
>>>
>>> normative source: x MUST NOT do y
>>>
>>> target: x
>>>
>>> predicate: [target x] does y
>>>
>>> prescription level: not permitted
>>>
>>
>> The above is correct use of the *negative* prescription level
>>
>>
>>>
>>>
>>> Which so far we do not endorse.
>>>
>>>
>>>
>>> while:
>>>
>>> normative source: x MUST NOT do y
>>>
>>> target: x
>>>
>>> predicate: [target x] does not do y
>>>
>>> prescription level: not permitted
>>>
>>>
>>
>>
>> This second example should instead be:
>>
>>  normative source: x MUST NOT do y
>>
>>  target: x
>>
>>  predicate: [target x] does not do y
>>
>>  prescription level: permitted
>>
>>
>>
>> I would not want to push the argument in favour of 'allowing' or
>> 'accommodating'
>> the negative prescription levels too much. However, the main argument
>> in their favor seems to me to be the fact that they do already exist
>> as a standard in the relevant RFC and this is probably for a good
>> reason. After all, they need not exist in specifications either since
>> the requirement could have been written
>>
>>
>>  normative source: x MUST not do y
>>
>> But is there *ever* a subtle difference between
>>
>>  normative source: x MUST not do y
>>  and
>>  normative source: x MUST NOT do y
>>
>> ?
>>
>> I suspect there is but that to regard the MUST NOT as redundant in
>> favor of 'MUST not' is probably not going to do much harm. It might
>> be worth endorsing a three-positive-value-only prescription level
>> codelist just for the benefit of being able then to say that a
>> predicate MUST always evaluate to 'true' when fuliflling the
>> normative requirement(s). So I'm happy to drop the argument since
>> there is some benefit in doing so and the benefit of keeping the 'MUST NOT'
>> equivalent Prescription Level and 'SHOULD NOT' equivalent is not easy
>> to see or demonstrate. However I have a feeling it does exist in more
>> complex cases - but that can be left to a more advanced treatment of
>> TAs which might endorse the corresponding extension of the
>> prescription level list.
>>
>> Best regards
>>
>> Steve
>>
>> --
>> Stephen D. Green
>>
>> Document Engineering Services Ltd
>>
>>
>>
>>
> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>>
>>
>>
>> 2008/11/27 Durand, Jacques R. <JDurand@us.fujitsu.com>:
>>>
>>> I think we have an ambiguity in current TAG draft, revealed by the
>>> SCA use
>>> case:
>>>
>>> - When a normative statement is of the kind "x MUST NOT do y" , the
>>> natural way (in fact, the recommended way) to write the predicate is:
>>> "[target x] does not do y"
>>>
>>> Then, what should be the prescription level?
>>> (a) MANDATORY?
>>> (b) NOT PERMITTED?
>>>
>>>
>>> (a) is aligned with both our definiions of predicate and of
>>> prescription level in 2.1:
>>>
>>>    Predicate
>>>
>>> A predicate asserts, in the form of an expression, the feature (a
>>> behavior or a property) described in the referred specification
>>> statement(s). If the predicate is an expression which evaluates to
>>> "true" over the test assertion target, this means that the target
>>> exhibits this feature. "False" means the target does not exhibit
>>> this feature.
>>>
>>>    Prescription Level
>>>
>>> A keyword that qualifies how imperative it is that the requirement
>>> referred in Normative Source, be met. See possible keyword values in
>>> the Glossary.
>>>
>>>
>>>
>>> (b) is aligned with the Glossary definition of prescription level :
>>>
>>>
>>>
>>>     The test assertion defines a normative statement which may be
>>> mandatory (MUST/REQUIRED), not permitted (MUST NOT), permitted
>>> (MAY/OPTIONAL) preferred (SHOULD/RECOMMENDED) or not recommended
>>> (SHOULD NOT). This property can be termed its prescription level.
>>>
>>>
>>>
>>> The problem I see with allowing/recommending "negative" prescription
>>> levels, is that this entices the TA writer to write "negative"
>>> predicates (=true means violation), e.g.:
>>>
>>>
>>>
>>> normative source: x MUST NOT do y
>>>
>>> target: x
>>>
>>> predicate: [target x] does y
>>>
>>> prescription level: not permitted
>>>
>>>
>>>
>>> Which so far we do not endorse.
>>>
>>>
>>>
>>> while:
>>>
>>> normative source: x MUST NOT do y
>>>
>>> target: x
>>>
>>> predicate: [target x] does not do y
>>>
>>> prescription level: not permitted
>>>
>>>
>>>
>>> Would be confusing and sound like a double negation ("not permitted"
>>> for target to NOT do y)
>>>
>>>
>>>
>>> Do we really need negative prescription levels, and if yes how do
>>> they work?
>>>
>>>
>>>
>>> Jacques
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
> --
> Stephen D. Green
>
> Document Engineering Services Ltd
>
>
>
> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>



--
Stephen D. Green

Document Engineering Services Ltd



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