[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Function Completeness
Greetings, I think we have a small problem with the completeness of all the things the functions can say. I fear that using "function:not" explicitly to cut down on defining some functions may not be sufficient for our purposes. We had originally decided to use an application of "function:not" on expressions involving "function:integer-equals" to get an equivalent to something like "function:integer-not-equals". Now, although it doesn't really make sense to write *Match rules, such as <ResourceMatch MatchId="function:integer-not-equals"> <AttributeDesignator AttributeId="weight"> <AttributeValue>300</AttributeValue> </ResourceMatch> but it does make sense to write such rules as: <ResourceMatch MatchId="function:integer-less-than"> <AttributeDesignator AttributeId="weight"> <AttributeValue>300</AttributeValue> </ResourceMatch> However, we currently don't have "less-than" because we agreed that we could use (not greater-than-or-equal). This situation is currently only a problem in the *Match functions. I had originally thought about it in the higher order functions, but figured we could get around it by reversing arguments and/or by applications of DeMorgan's Law. For example, any-of (not . f) xv1 xs2 where ( . ) is the function composition operator. is the same as not (all-of f xv1 xs2) for all predicates, f. and any-of (not . f) xv1 xs2 is the same as not (all-of g xv1 xs2) where the argument order of f does matter, such as in "not . integer-greater", and g is the negated dual, such as "integer-greater-than-or-equal" So if we wanted: any-of integer-less-than xv1 xs2 we could use: not (all-of integer-greater-than-or-equal xv1 xs2) and we wouldn't need to introduce "integer-less-than". But anyway, we do have a problem for the *Match. Either we introduce functions such as "integer-less-than", and quite possibly, things like "integer-not-equals" for each type, so that they can go into the MatchId, or we can specify an attribute on *Match and as well on Function elements to be consistent. Its kind of hokey, but I don't think there is any thing egregious about it, since the composition with negation is quite simple, i.e. negation of a boolean result is very standard. For an example, let me relate a <ResourceMatch> and its <Apply> equivalent with the higher order functions: <ResourceMatch MatchId="function:integer-greater" Negate="true"> <AttributeDesignator AttributeId="weight"/> <AttributeValue>300</AttributeValue> </ResourceMatch> and <Apply FunctionId="function:any-of"> <Function FunctionId="function:integer-greater" Negate="true"> <AttributeValue>300</AttributeValue> <AttributeDesignator AttributeId="weight"/> </Apply> which both which have the effect of applying the function composition (not . integer-greater) to the value 300 and bag of values returned from the desingator. These expressions get us "true" if a "weight" attribute exists, and it is less than or equal (i.e. not greater) to 300. It's pretty simplistic, we aren't going for full fledged function composition, just a straight negation of a boolean result when evaluated. What do people think on the problem, and the proposed solution? Cheers, -Polar
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC