[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag] ambiguity in current TAG draft
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:
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]