Re: [tag] About Prescription levels

[stephen.green@systml.co.uk]

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