OASIS eXtensible Access Control Markup Language (XACML) TC

RE: [xacml] Function Document Issues

  • 1.  RE: [xacml] Function Document Issues

    Posted 08-26-2002 14:16
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


    Subject: RE: [xacml] Function Document Issues


    
    Aside from writing policies which depend on ERRORs happening, a policy
    writing methodology that I abhore, I would rather have a separate function
    called "on-error" specifying a value of a specific type.
    
    -Polar
    
    On Mon, 26 Aug 2002, Daniel Engovatov wrote:
    
    > On Mon, 26 Aug 2002, Daniel Engovatov wrote:
    >
    > > 2. "and" and "or", "n-of" functions. I think they are unnecessary in
    > >    contrast to their "ordered-*" counterparts. Since we are now
    > >    paying explicit attention to ERROR when evaluating policy, I think we
    > >    should just go with the "ordered" versions of these functions for
    > >    explicitly determinate results.
    > >
    > > Agree on "and" and "or" - should just leave ordered ones (or, rather,
    > > rename them to be "and" and "or"
    > >
    > > "n-of" is a different thing - does not have an alternative - and does
    > > not suffer from the current "or"/"and" indeterminate result - due to
    > > indeterminate evaluation order - issue..
    >
    > >It certainly does. There is nothing to say in the "n-of" case that
    > >stipulates that the arguments need to be evaluated in first to last order.
    > >For example, they can be evaluated from last to first, which when taking
    > >into account for ERROR alters the evaluation.
    >
    > Hm.. It was then lost by s at some point.
    > We may want to keep current "or" and "and" and "n-of" is we specify that
    > they treat ERROR arguments same as "false" (absorb errors)..  So that they
    > never return ERROR.  Kinda error catching function - you may use them to
    > wrap other predicates if you want to never return ERROR.
    >
    > For example (or (integer-greater (integer-divide 1 0) 5))  will not return
    > ERROR ever, unlike just using "greater"
    >
    > Then "ordered-" versions will specify that the ERROR is returned if
    > an argument of ERROR value is encountered, as it is specified now...
    >
    > Daniel.
    >
    > ----------------------------------------------------------------
    > To subscribe or unsubscribe from this elist use the subscription
    > manager: <http://lists.oasis-open.org/ob/adm.pl>
    >
    
    


    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


    Powered by eList eXpress LLC