[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] Match/No-Match Semantics
On Tue, 27 Aug 2002, Daniel Engovatov wrote: > I agree that it was a wrong decision.. > > Proposal: > > Treat Match evaluation as part of the rule evaluation, combined with > the condition with an AND, according to the described AND semantics. > > So for a rule for(... match()) if condition() > evaluated expression is: match() AND condition() > > With the result being processed by the rule recombination algorithm. > So that Indeterminate in Match() will be treated as Indeterminate() > result of a rule, applied. This approach would work because a rule should be interpreted roughly as Target -> (Condition -> Effect) where "->" is "implies" in classical logic. And that formula is equivalent to (Target AND Condition) -> Effect in classical logic. Cheers, -Polar > -----Original Message----- > From: Polar Humenn [mailto:polar@syr.edu] > Sent: Tuesday, August 27, 2002 6:13 PM > To: XACML > Subject: [xacml] Match/No-Match Semantics > > > > Greetings, > > Apparently we have what I believe is an inconsistency in the evaluation of > the rules with respect to expressions resulting in errors and the target > match semantics. > > For the Target we have only two values Match and No-Match, and have said > that if an error occurs while evaluating the target, the result is a > No-Match. > > If we evaluate equivalent expressions, one in the target, the other in a > condition, we would get two different results. > > For example, let's say we have a situation such that an > AttributeDesignator is not available, and any call to it will result in an > operational error. > > Let's say we have a rule with an ANY target and a condition that performs > a match on this AttributeDesignator. The result of the condition is > Indeterminate, and therefore the rule is evaluated to Indeterminate. > > Let's also say we have a rule with a target that performs the equivalent > match on that particular designator. We have said that we map any Error to > a No-Match situation. In that case, then the rule is evaluated to > NotApplicable. > > Does this situation sit right with people? > > Cheers, > -Polar > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > 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