OASIS eXtensible Access Control Markup Language (XACML) TC

  • 1.  And, Or, and N-Of

    Posted 07-10-2003 19:04
    
    Also, I'm a little concerned about the definitions of and, or, and n-of. 
    It seems that we changed the last sentence of each of these descriptions 
    from:
    
    	If any argument while being evaluated according to this order
    	raises an error, the expression SHALL return "Indeterminate".
    
    to
    
    	In an expression that contains any of these functions, if any argument is 
    	"Indeterminate", then the expression SHALL evaluate to
    	"Indeterminate".
    
    Aside from being a horrible sentence (did I write that? :), it changes the
    meaning entirely.
    
    The first sentence said that in evaluating the arguments if you 
    encountered an error along the way, it should render the entire expression 
    Indeterminate. I don't really agree with this evaluation either.
    
    The second sentence says that if an application of this function appears
    in an expression, all the arguments MUST be guaranteed that they will not
    evaluate to Indeterminate (i.e. the evaluation engine has all the data it
    can possibly have for evaluation, and can also assert that there is no
    possibility for things like divide-by-zero, etc.), That doesn't guarantee
    that they have to be evaluated.
    
    Why did we go this way? Was it to make sure that errors no matter where 
    they occurred showed up through the entire evaluation?
    
    I think the evaluation should be: ("_|_" equates with indeterminate)
    
    (and false _|_ ) = false
    (and true  _|_ ) = _|_
    (or true   _|_ ) = true
    (or false  _|_ ) = _|_
    
    (and _|_ false ) = false
    (and _|_ true  ) = _|_
    (or  _|_ true  ) = true
    (or  _|_ false ) = _|_
    
    However, the first sentence, no defunct, follows this semantics:
    
    (and false _|_ ) = false
    (and true  _|_ ) = _|_
    (or true   _|_ ) = true
    (or false  _|_ ) = _|_
    
    (and _|_ false ) = _|_
    (and _|_ true  ) = _|_
    (or  _|_ true  ) = _|_
    (or  _|_ false ) = _|_
    
    And, the second sentence follows this semantics:
    
    (and false _|_ ) = _|_
    (and true  _|_ ) = _|_
    (or true   _|_ ) = _|_
    (or false  _|_ ) = _|_
    
    (and _|_ false ) = _|_
    (and _|_ true  ) = _|_
    (or  _|_ true  ) = _|_
    (or  _|_ false ) = _|_
    
    The second sentence, which is our current specification, means for the 
    large part, that most evaluation engines must evaluate ALL the arguments 
    for AND, OR, and N-OF, regardless of any evaluation order.
    
    Is this what we wanted? I cannot remember.
    
    Cheers,
    -Polar