Re: [xacml] Functions Document again.

[Polar Humenn <polar@syr.edu>]

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
>
> ----- Original Message -----
> From: "Polar Humenn" <polar@syr.edu>
> To: "XACML" <xacml@lists.oasis-open.org>
> Sent: Monday, August 26, 2002 12:25 PM
> Subject: [xacml] Functions Document again.
>
>
> >
> > "and", "or" and "n-of" now hwave the semantics of their "ordered-*"
> > counter parts, and the "order-*" names have been removed.
> >
> > Two new functions for catching the ERROR condition.
> >
> > type-on-error
> >
> > type-sequence-on-error
> >
> > Each of which take two arguments, of which the second argument is a
> > "default" value for the expression should evaluating the first argument
> > result in ERROR.
> >
> > We still need specifications for all the matching and equals functions!
> >
> > Cheers,
> > -Polar
> >
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>