RE: [tag] ambiguity in current TAG draft

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

 Stephen:
Inline <JD>

-----Original Message-----
From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
Sent: Thursday, November 27, 2008 1:37 PM
To: Durand, Jacques R.
Cc: tag@lists.oasis-open.org
Subject: Re: [tag] ambiguity in current TAG draft

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

<JD> then we have to make it clear that the PL always qualifies the result of the Predicate (meanig here: "it is not permitted that [target x] does y") as far as fulfillment to the norm source is concerned.  So the PL does NOT merely reflect the normative keyword (MUST NOT). In some cases, it will not: it all depends on how the Predicate is worded. E.g. this is also correct I assume:

-normative source: x MUST NOT do y

-target: x

-predicate: not ( [target x] does y )

-prescription level: mandatory



>
>
> 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

<JD> But it is not just "permitted": it is mandatory that x MUST NOT do y, which is logically equivalent to say that it is mandatory that x MUST {not do y} as you noted before. Because if you say "permitted" that means its OK to do otherwise.



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

<JD> Right - I believe the introduction of "negative" keywords (MUST NOT, SHOULD NOT) is just a convenience to avoid confusion, i.e. if the "not" looks smaller than the "MUST", people may just see / remember the MUST... and make a mistake. Exception made for MAY NOT / MAY not (see below).

?

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.

 

<JD> Right. After reading the SCA TAs draft  I feel that it would be confusing to explain people they can as well use negative PLs. I am afraid that will give them an opportunity to screw up (e.g. use a negative predicate for a MUST NOT and yet use a "negative" PL that will double-neg the requirement). Frankly I think our current 3 "positive" PLs can apply to negative keywords as well, because we took great care of choosing a terminology different from RFC keywords:

- "mandatory" can then apply to both MUST and MUST NOT,

- and likewise for "preferred" (SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED)

- and "permitted" (MAY, OPTIONAL)

I think the MAY NOT falls under the "mandatory" category (understood as "cannot" i.e. a MUST NOT) while a "MAY not" is just an option ("permitted")

 

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
>
>
>
>
>
>