RE: [xacml] RE: Your input needed on Comment#33. Forwarded messag efrom Daniel Engovatov.

[Daniel Engovatov <dengovatov@crosslogix.com>]

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>