OASIS eXtensible Access Control Markup Language (XACML) TC

Re: [xacml] Functions Document again.

  • 1.  Re: [xacml] Functions Document again.

    Posted 08-26-2002 16:04
     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
    >
    >