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