RE: [xacml] [Issue] Would it be SO bad if we dropped the <Function> element?

[Tim Moses <tim.moses@entrust.com>]

Polar - OK.  Thanks for reminding me.  With your permission, I will
"improve" the text in Section 5.25 (the explanation of <Function>).  I think
it should say that it is only used if the parent <Apply> element takes a
function name as an argument (for example, if it is one of the standard
higher-order bag functions) and that (in this case) the function MUST return
a boolean result.

At the moment, the text says that the <Function> element is only present
when the parent <Apply> element is one of the standard higher-order bag
functions.  I think you are suggesting its use could be more general.

I hope you are fully enjoying the quiet time before the onslaught starts
again.  Speak to you soon.  All the best.  Tim.

-----Original Message-----
From: Polar Humenn [mailto:polar@syr.edu] 
Sent: Monday, December 29, 2003 12:05 PM
To: Tim Moses
Cc: 'XACML'
Subject: Re: [xacml] [Issue] Would it be SO bad if we dropped the <Function>
element?




Hi Tim!

Hope you had a happy holiday, and continue to do so! It's really quiet
around here without the students!

On Mon, 29 Dec 2003, Tim Moses wrote:

> Colleagues - Do we need to retain the <Function> element?  I believe 
> its purpose can be served by the <Apply> element when the FunctionId 
> attribute identifies one of the bag functions.

The <Function> statement only names the function as an argument to the
Higher Order Bag functions in standard XACML.

> We already allow a similar special case in the <Condition> element, 
> which is an <Apply> element whose FunctionId attribute must identify a 
> function whose return type is boolean.

The <Condition> element is a pedantic feature, and is really not needed.
Just by the placement of the condition statement, i.e. in a rule, it should
have been any boolean value, whether a from an Apply statement, or not. I
can't remember why we when with it, however.

In fact the Condition function causes problems for code generation whereby
you want the condition to be true or false without having to apply some
function to get the simple boolean answer.

> As currently structured, the bag function does not "enclose" the 
> attributes or functions to which it applies.

That's right. It tags the function as a special value, i.e. because
attribute value only covers data types.

> If we require the use of the <Apply> element instead, the bag function 
> can enclose the attributes or functions to which it applies.  See 
> lines [a477] to [a491] in draft 3.  Doesn't this make more sense?

The Bag functions work just like any other function without distinction. A
higher order bag function is applied to its arguments enclosed in the
<Apply> statement, just like any other function, except one of its arguments
is a function instead of a data type. There are no special conditions on the
Apply statements based on the function called, higher order or not.

I would like to keep it that way. The <Function> statement, names a function
as an argument to another function.  That <Function> statement, used as an
argument, can be used for any other higher order functions in functions in
Extended XACML, and these <Function> statements can be applied at any
argument position depending on the definition of the extension function.

It would be bad if it went away.

Cheers, and happy new year!
-Polar