OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [xacml] Function Document Issues

On Mon, 26 Aug 2002, Daniel Engovatov wrote:

> 2. "and" and "or", "n-of" functions. I think they are unnecessary in
>    contrast to their "ordered-*" counterparts. Since we are now
>    paying explicit attention to ERROR when evaluating policy, I think we
>    should just go with the "ordered" versions of these functions for
>    explicitly determinate results.
> Agree on "and" and "or" - should just leave ordered ones (or, rather,
> rename them to be "and" and "or"
> "n-of" is a different thing - does not have an alternative - and does
> not suffer from the current "or"/"and" indeterminate result - due to
> indeterminate evaluation order - issue..

>It certainly does. There is nothing to say in the "n-of" case that
>stipulates that the arguments need to be evaluated in first to last order.
>For example, they can be evaluated from last to first, which when taking
>into account for ERROR alters the evaluation.

Hm.. It was then lost by s at some point.
We may want to keep current "or" and "and" and "n-of" is we specify that 
they treat ERROR arguments same as "false" (absorb errors)..  So that they
never return ERROR.  Kinda error catching function - you may use them to
wrap other predicates if you want to never return ERROR.

For example (or (integer-greater (integer-divide 1 0) 5))  will not return 
ERROR ever, unlike just using "greater" 

Then "ordered-" versions will specify that the ERROR is returned if
an argument of ERROR value is encountered, as it is specified now...


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC