[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] RE: Your input needed on Comment#33. Forwarded messag efrom Daniel Engovatov.
Let me elaborate a bit on why I agree with Seth. Since the function name (and therefore type) is a parameter for the map function, you do not now what type it will return until you now the value of this parameter. In the current, limited functionality system we do no the value at the "compile" time. To provide a uniform extensibility mechanism for these "higher" order functions, we may need to allow the value of each argument to be a parameter with a value determined at the runtime. In this case the functions that take this map output as an argument can not be verified to accept the correct data type in advance. In the case that the map type is declared and the function name is a runtime valued parameter - inappropriate name will result in an Indeterminate: a condition that we have a clear mechanism to deal with. For this reason - ALL XACML functions should have declared, not deduced, type. -----Original Message----- From: Seth Proctor [mailto:seth.proctor@Sun.com] Sent: Friday, November 22, 2002 10:17 AM To: Polar Humenn Cc: Anne Anderson; XACML TC Subject: Re: [xacml] RE: Your input needed on Comment#33. Forwarded message from Daniel Engovatov. > The type of the map function is deduced by the function parameter and the > other argument has to coincide. This sounds similar to the argument for not including the DataType attribute in AttributeValues. The whole idea is that we should be able to look at an attribute, a function, a designator, etc., and know what type it will be returning. Without that, there is no strong type-system. > What would "integer-map" mean? Would that mean a transformation of a bag > of integers to integers? Somehow, that would defeat the purpose of the > brevity of the specification, especially if you wanted to convert doubles > to integers, or dates to strings, etc. No. The integer-map function would be a function that returns a bag of integers, and therefore expects a function that also returns integers. It would mean nothing more. You could still have a function that converts doubles, strings, etc to integers. The return type of a function does not limit what it accepts or works with internally. This would be consistent with the rest of the sepc, and would require a minimal number of additional functions. seth ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
Powered by eList eXpress LLC