[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] [Issue] Would it be SO bad if we dropped the <Function> element?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]