RE: [tag] About Prescription levels

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

Stephen:

Agree with your concerns of making sure the predicate interpretation
does not get blurred in the process:

> If the spec says MUST or MUST NOT and this is all captured in the
prescription level 
> then what more is there to say with 'outcome'?
> Doesn't this introduce an unnecessary extra way to add a negation.

I think we have here two problems that will collide if we don't
establish clear semantics boundaries:

(1) problem of conveying the "level of prescription" associated with the
normative source (mandatory, recommended/preferred....) 

(2) problem of establishing the meaning of the predicate w/r to
fulfillment of normative source.

----- For (1):

We are facing two major options:

Option (A):  the prescription level is nothing more than a "category" of
normative statement. For example, if a normative feature has the
RECOMMENDED keyword, then the prescription level is "preferred". Even if
this TA is later reused for a conformance profile #2 for this
specification, that makes the feature REQUIRED. (the feature remains
optional for the "base" conformance profile #1). In that case we leave
it to the Test Cases / Test Suite associated with each Profile, to
interpret its outcome differently. 

Option (B): the prescription level reflects the expectation of
fulfillment for a target, with regard to this TA. In that case, we would
have two TAs for profiles #1 and #2, that would only differ by their
prescription level: "preferred" for #1, "mandatory" for #2.

I believe the initial intent for prescription level was (A) (Paul?
Yongkon?). 
I feel (B) would be tricky and taint the TA with some conformance
expectation that would go beyond the "statement of behavior, action or
condition that can be measured or tested" which we could claim is the
same in both cases. ( also consistent with these TAs that are used just
to verify if a target exhibits a feature, regardless of conformance
concerns.)
But as a TC we need to come to some closure on this.


----- For (2):

I send back to recent examples in a previous email (6/18 titled "weak TA
predicates".)
These examples have led people to define TAs with a predicate that is
intentionally too "weak" to permit the usual mapping: 
- true = [indication of] fulfillment [of normative feature], 
- False = [indication of] violation [of normative feature]
But instead, lead to cases such as:
- true = fulfillment, 
- False = undetermined 
Or:
- true = undetermined, 
- False = violation

And I distinguish these variations from conformance outcomes that I
think Patrick mentioned previously: that in all cases, when looking at a
test result, a failure outcome surely means a violation of the spec
feature, while a positive outcome is no guarantee that this target will
always fulfill the spec requirement in the future. I believe this is
always true even with a "perfect" predicate (True=fulfillment,
False=violation). But these variants above are of different nature:
caused by the design of the predicate itself, i.e. by design (for
testability reason) incapable of indicate either fulfillment or
violation.

Such cases seem to beg for a better statement of the relationship
between predicate and normative feature, i.e. how good a "measurement
indicator" the predicate is, by mapping true/false outcome to what is
"indicated" (fulfillment, violation, undetermined). 
Now, if we do this, should we also allow mappings like (negative
testing):
- true = violation, 
- False = fulfillment
Or:
- true = violation, 
- False = undetermined
I feel we don't have to, but this is a lesser question...

But these concerns should remain othogonal to the "prescription level",
whatever semantics it is given (A) or (B) above. I.e. the design quality
of the predicate is a different issue from how strongly the fulfillment
(of which the predicate is just an indicator), is expected from a
target.

So I believe these two problems (1) and (2) above, if kept orthogonal,
are manageable... And certainly should avoid the "composed negation"
confusion IF prescription level is interpreted as (A), or even in case
we want (B) if we are careful to define it as a prescription of
"fulfillment", not of what the predicate outcome is which could mean
different things in (2).   

I hope at least I stated the problems correctly...

Jacques




-----Original Message-----
From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk] 
Sent: Saturday, June 14, 2008 2:49 PM
To: tag@lists.oasis-open.org
Subject: Re: [tag] About Prescription levels


>> Why not then just 5 values:
>
> That sounds sufficient to me. Also missing, other keywords mappings:
>
> For REQUIRED -- 'mandatory'
> for NOT RECOMMENDED -- 'preferred not'
> Etc.
>
> regarding:
> for MAY -- 'optional'
> I have a slight preference for the initial suggestion from Patrick:
> "permitted". Because "optional" is already - when capitalized - used 
> as a RFC2119 reserved keyword (raising question why do we elect this 
> one out and not others?), and also I feel "permitted" contrasts better

> with "preferred" which is in fact also about an optional (yet 
> preferred) feature...

Interesting to me is the emphasis for some reason on which outcome it is
which is 'permitted'. To me 'optional' implies that the 'false'
outcome is the one which is 'permitted' but I can't think why I get that
impression because it also seems logical that if one outcome is
'permitted'
then it follows that the other outcome is too.

>
> I think that if we try to go deeper into giving more meaning to the 
> prescription level (e.g. w/r to conformance to spec) we'll get into a 
> rat hole...

I agree - 'no more complex than necessary but no less complex either'

>
> That is why I am also bringing back the notion of "outcome 
> interpretation" on the table, because if there is a need to be more 
> specific about what the TA outcome means w/r to the specification 
> fulfilment, I'd rather leave that to another TA element other than 
> "prescription" which was supposed to only capture the original info in

> the spec if I recall.

If the spec says MUST or MUST NOT and this is all captured in the
prescription level then what more is there to say with 'outcome'?
Doesn't this introduce an unnecessary extra way to add a negation.
Doesn't it create the possibility of a triple negative while not adding
anything we don't have already? Is seems that the predicate can be
negated using an 'outcome interpretation, yes. Is this desirable though?
Is it so that there can be inclusion or exclusion of the third outcome
interpretation of 'not applicable'? Aren't there side-effects though
such as:

1. possible confusion over the logic involved in combining prerequisite,
    predicate, prescription level and outcome interpretation
    (does outcome int'n apply to predicate or to some combination
     of predicate, prerequisite, etc? how does outcome int'n affect
     the use of the TA as a prerequisite to another TA?)

2. there would be a third place to put a negation resulting in
    the possibility of a triple negative and uncertainty if such
    a TA is mistaken since some might regard a triple negative as
    a positive while other might assume it is an oversight and take
    it as a negative

Conclusion: If there were an outcome interpretation element I'd want to
go back to using just the three positive values for prescription level
and eliminate the default true value for outcome since is it more likely
it will be negative to cater for MUST NOT and SHOULD NOT.
I'd want to make outcome essential and NOT defaulted to true. Perhaps
four-valued - 'true/false', 'false/true', 'true/not applicable' and
'false/not applicable' A in A/B is the outcome for a positive predicate
result and B is the outcome for a negative or unknown result.
Clearly it gets very complex. To me this would be perhaps too complex
for the simple guide so it would be convenient to be able to defer it to
any advanced, follow-up document.

Best regards

Steve

>
> Cheers,
> Jacques
>
> -----Original Message-----
> From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk]
> Sent: Friday, June 13, 2008 9:38 AM
> To: tag@lists.oasis-open.org
> Subject: Spam: Re: [tag] About Prescription levels
>
> How about this example:
>
> "The button MUST NOT have colors black and blue together or red and 
> green and grey together or red and white and a color other than
orange."
>
> Negating this to allow for a positive prescription level does seem 
> problematic. The problem is the 'and', 'or', etc along with existing 
> negation.
>
> Isn't it a problem that
>
> A AND B
>
> when negated is
>
> Not A OR Not B
>
> when so many forget and write 'Not A AND Not B' (or at least I 
> sometimes have done while in my early programming days).
>
>
> Why not then just 5 values:
>
> For MUST -- 'mandatory'
> for MUST NOT -- 'not permitted'
> for SHOULD -- 'preferred'
> for SHOULD NOT -- 'preferred not'
> and for MAY -- 'optional'
>
> Then we can put simply, in prose without being forced to use a logic 
> expression like Not(A AND B):
>
>
> "The button does have colors black and blue together or red and green 
> and grey together or red and white and a color other than orange."
>
> PL: 'not permitted'
>
> --
> Stephen D. Green
>
> Partner
> SystML, http://www.systml.co.uk
> Tel: +44 (0) 117 9541606
>
> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  You may a link to this group and all your TCs in

> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  You may a link to this group and all your TCs in

> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php