Re: [tag] ambiguity in current TAG draft

["Stephen Green" <stephen.green@documentengineeringservices.com>]

Jacques,

Yes, I think this is a very helpful clarification

2008/12/3 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
>



-- 
Stephen D. Green

Document Engineering Services Ltd



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