OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: And, Or, and N-Of



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



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