OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

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

  • 1.  Re: [xacml] RE: Your input needed on Comment#33. Forwarded messagefrom Daniel Engovatov.

    Posted 11-22-2002 13:19
     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 messagefrom 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
    


    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


    Powered by eList eXpress LLC