Re: [xacml] re: functions

[Polar Humenn <polar@syr.edu>]

On Mon, 26 Aug 2002, Simon Godik wrote:

> Polar,
>
> I agree with the approach where where ERROR in evaluating 'or', 'and'
> is used as placeholder until all components are evaluated.

Then ERRORs magically disappear.

> Then, if ERROR can be substituted with either (true, false) without changing result, result is returned.
> If this substitution can not be made, error is returned.

> 'and': false, ERROR, true -> false
> 'and': true, ERROR, true -> ERROR
> 'or': false, ERROR, true -> false
> 'or' true, ERROR, true -> true

I don't care one way or the other. Its just that if you get an ERROR you
have to "hold on to it" and keep evaluating. If everyone is into that,
it's fine with me.  It's almost a little more consistent than ignoring the
ERROR if the evaluation were not to proceed.

I'll change it to fit your scenarios.

> I'm still not sure what is the purpose of error functions.
> If an error is raised, there is a prescription of what must be done
> during condition evaluation and rule evaluation.
>
> Even if we had error functions there is no syntax to accomodate them.
> Also, what to do if error-handling function is raising an error, such
> as invalid default value etc?

This would be just like any try - catch senario. If there is an error in
the catch clause, the error is raised.

<Apply FunctionId="boolean-on-error">
	<some boolean expression>
        <AttributeValue dataType="xs:boolean">false</AttributeValue>
</Apply>

The error functions "wrap" the first argument. Only if there is an ERROR
in the first argument, the second argument is evaluated. If the second
argument is an ERROR then you have to wrap that expresion or the whole
thing with an error function.

<Apply FunctionId="boolean-on-error">
	<Apply FunctionId="boolean-on-error">
		<some boolean function>
		<some other boolean function>
	</Apply>
        <AttributeValue dataType="xs:boolean">false</AttributeValue>
</Apply>

Cheers,
-Polar
 >
> Simon
>
>
>