OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]