OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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

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

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


> -----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