Re: [xacml] functions issues

[Polar Humenn <polar@syr.edu>]

On Tue, 27 Aug 2002, Simon Godik wrote:

> I'm ok with the way 'or', 'and' are descirbed in the latest document:
>
> 'or': First to last, 'true' if one arg evaluates to 'true'. If any arg raises an error, return an ERROR.
> 'and': First to last, 'false' if one arg evaluates to 'false'. If any arg raises an error, return an ERROR.
> In any case, if definitive result can be concluded, the rest of the args is not evaluated.
>
> Here is a variation that forces all args computation, even in the presense of an error:
> (Longer, but gives your a better chance to succeed):

Actually, the "variation" a better approximation to the formal result, and
it sort of matches the semantics that we have chosen for our combinators.

> Compute all 'and', 'or' args first to last. If 'error' is raised use it as placeholder until all computation is complete.
> If 'error' could be substituted with either (true, false) without changing an outcome, return outcome.
> Otherwise return error.

> In any case, I do not see any errors being 'hidden', meaning changing an outcome of computation.
> Simply some errors are relevant and some are not.

> I do not agree with defining error functions and default values.

I don't see what the big fuss is. The fact is that if you have errors, you
notice them, it follows that you just may want to handle them, and then
you should have formal mechanisms to do so. I'm just trying to be
thorough and complete. However, I'll take them out.

Further more, I would like to know what happens when a SubjectMatch or
ResourceAttributeSelector, or ActionMatch results in an ERROR for the
target of a rule, a policy?

Cheers,
-Polar