OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

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

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

    Posted 11-25-2002 10:44
     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 Mon, Nov 25, 2002 at 10:29:03AM -0500, Polar Humenn wrote:
    > What we have here is the generic application of the SAME FUNCTIONALITY, so
    > why give the same functionality different names?
     
    Because this is how it is done with every other function in the spec. As a
    result, you need this for the map function too if you want consistency. Yes,
    I see the value of having a generic function that can map any type to any
    type, but it breaks the type system that the rest of the spec has defined. Both
    Daniel and I are speaking from an implementors point of view, and we both
    see the muddle that occurs when you have this special-case function. The clean
    definitions in the spec completely break when you allow the map function to
    not have its return type explicitly defined.
    
    Implementors will already need to define things like -equal, or -one-and-only,
    or -union for their new attribute types. Redefining the map function doesn't
    change this. A good implementation will let a programmer do this with a
    minimum of effort, but it is still necessary. To maintain consistency, and
    to keep the type system intact, the map function must become type-map.
    
    
    seth
    


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


    Powered by eList eXpress LLC