OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

RE: [xacml] xpath-expression datatype

  • 1.  RE: [xacml] xpath-expression datatype

    Posted 08-26-2004 20:15
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

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


    Subject: RE: [xacml] xpath-expression datatype


    
    Once again, I will refer you back to my original email on this topic.
    The thread started because I don't think we should include the
    xpath-expression datatype in the core specification. Please read the
    whole thread.
    
    > I don't care about the example. Let the example show the capabilities of
    > the language, whatever the capabilities are.
    
    Yes you do, because I will say again that I'm only talking about one
    isolated example. I do not want to confuse the whole specification for
    the sake of one example.
    
    > The fact that the <AttributeValue> is typed an XPATH expression allows
    > that value to be checked before it is applied in some XPATH function,
    > especially in the request.
    
    But it's useless in this case, because we have no functions that will
    use this datatype (see below). 
    
    > However, it does bring up an interesting point.  In fact, I would lobby
    > that the XACML XPATH functions
    > 
    > urn:oasis:names:tc:xacml:1.0:function:xpath-node-count
    > urn:oasis:names:tc:xacml:1.0:function:xpath-node-equal
    > urn:oasis:names:tc:xacml:1.0:function:xpath-node-match
    > 
    > should be changed to take an "#xpath-expression" instead of a "#string",
    > unless there is some need to dynamically create the XPATH expression
    > argument, using such things as string-cat, substring, etc.
    
    And we're back to my original email. Yes, I think there is value in
    being able to construct these XPath expressions on the fly. Separate
    from that, I think it's really late in the game to talk about breaking
    compatability with these functions. I do not think we should change the
    parameters now, so I do not believe there's any value in including the
    xpath-expression datatype in the core specification.
    
    
    seth
    
    


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