[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