MHonArc v2.5.2 -->
















xacml message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]








Subject: [xacml] Function Completeness




From: Polar Humenn <polar@syr.edu>
To: XACML <xacml@lists.oasis-open.org>
Date: Wed, 18 Sep 2002 11:33:07 -0400 (EDT)







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