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 11:26
     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, 25 Nov 2002, Seth Proctor wrote:
    
    >
    > 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.
    
    Not true. "integer-equal" is fundementally different that "string-equal",
    etc.  Map is generic, or polymorphic over "bags".
    
    And, "integer-equal" specifies a function that determines equality over
    integers (i.e. as arguments). If you took your approach to naming the map
    functions, e.g. "integer-map" naming the resultant type only, then to be
    "consistent" you would really have to name the "integer-equal" function as
    "boolean-equal", which doesn't make sense.
    
    
    > 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