MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [xacml] Functions Document again.
On Mon, 26 Aug 2002, Simon Godik wrote:
> Polar,
> did we agree that we want ordered 'or' etc only?
I know, I know, but we must now worry about evaluation/operational ERRORs.
Therefore, to maintain deterministic consistency we must have to
explicitly call out the evaluation order with respect to ERROR. This
specification doesn't limit the evaluation of the constituents to any
particular evaluation order, such as parallel order. The only thing that
must be preserved is that if you are going to get an error evaluating it
happens in such a way that fits a certain evaluation strategy.
Let's say you evaluate all the constituents of an "and" in parallel and
they all finish at the same time. And their results are:
false ERROR true
Then acording to the specification, you would return false because the
first argument is false.
However, if the constituents of the expression evaluate to:
true ERROR false
then the result is ERROR, because the ERROR is before the false.
This approach just gives us some consistentcy in the evaluation.
I know it's border line silly in this case, but think of a combinator
that quits as soon as it hits an error.
> I think discussions at f2f indicated that unordered 'or' etc must be
> supported.
I think the only the only issue here is that the ERROR would be "ignored"
until an answer is found, i.e.
true ERROR true ERROR true true true .... false. ==> false
I think some people were against this approach.
> Why do we need on-error functions?
We need ERROR catching functions, because we now have to deal with ERRORS,
and I don't want them magically disappearing in ANDs or ORs.
If they are going to happen, we should have a mechanism to deal with them.
It's pretty standard fare, even in the functional programming world.
Cheers,
-Polar
> Simon
>
>