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


    
    On Thu, 2004-08-26 at 16:25, Polar Humenn wrote:
    > > > 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).
    > 
    > It is useful in the sense that you provide a ResourceContent, and the
    > resource-id is an XPATH pointer into that document. Then it had better
    > be a correct XPATH expression. Its type tells us so. And therefore its
    > useful.
    
    I think we're arguing at different points, based on what we're trying to
    make useful. You're talking about the general case, and I'm talking
    about the specific example (see below). What I want is for people to
    look at the example and easily understand what they're seeing, based on
    the rest of the content in the spec. I think that will be best served by
    using a datatype that works with functions in the spec.
    
    In general (again, see below), I agree completely that there is real use
    in having specific datatypes that let us validate incoming values.
    
    > > > 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.
    > 
    > Okay. That's good enough for me.
    
    Whew. :)
    
    > > Separate from that, I think it's really late in the game to talk about
    > > breaking compatibility with these functions.
    > 
    > That's right. Changing them would break backwards compatibility.
    > 
    > However, it would still be nice to have functions that took restricted
    > types for arguments so that they may be type checked.
    
    I agree. I think this is part of the recent discussions around IP
    addreses, regexp expressions, etc. too. 
    
    > > I do not think we should change the parameters now,
    > 
    > Agreed.
    
    Ok.
    
    > > so I do not believe there's any value in including the xpath-expression
    > > datatype in the core specification.
    > 
    > There I will differ.
    
    Sorry, what I mean is "value including it without updating functions and
    adding use of the datatype." Even still, you may disagree. Again, I
    think we're working on different priorities. If there is any follow-on
    work to 2.0, I would like to revisit this exactly as we have
    discussed...
    
    
    seth
    
    


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