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