[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]