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
From: Seth Proctor <>
To: Polar Humenn <>
Date: Thu, 26 Aug 2004 16:15:00 -0400
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
