[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... Daniel.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC