MHonArc v2.5.2 -->
xacml message
[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.
On Fri, 22 Nov 2002, Daniel Engovatov wrote:
> 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.
Declaring a type of a map function by putting the return type in the name,
such as "integer-map" doesn't mean much more than restricting the function
name to primitive types. Furthermore, you are only "declaring" a partial
type, because you are not "declaring" the type of the argument. Also,
"integer-map" sounds like you are going to be "mapping a bunch of
integers".
Also, this forces you to "invent" a name for each type you may introduce
into XACML for a map to all functions and have it work. For example, if
you invent a type "http://www.xyz.com/datatype#heathrecord"; and you have a
function called "function:RecordID" that takes an element of type
"http://www.xyz.com/Datatype@heathreaord"; and returns a
"http://www.xyz.com/datatype#RecordId";.
If you want to use a function then you have to define a function called
"?????-map" so it will map a bag of "http://....healthrecord"; to a bag of
"http:///....RecordId";. So, now you have to call it something.
Let me say that giving a rose another name, doesn't make it something
different than a rose.
What we have here is the generic application of the SAME FUNCTIONALITY, so
why give the same functionality different names?
The type of the map function is:
map :: (a -> b) -> [a] -> [b]
The definition of the map function is:
map f [] = []
map f (x:xs) = (f x) : (map f xs)
Where f is a function from type a to type b, and the function is just
applied to every element of the bag.
So why give it different names?
integer-map = map
string-map = map
date-map = map
duration-map = map
etc.
-Polar
>
> -----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>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC