RE: [xacml] xpath-expression datatype

[Polar Humenn <polar@syr.edu>]

> > 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.

> > 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.

> 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 do not think we should change the parameters now,

Agreed.

> so I do not believe there's any value in including the xpath-expression
> datatype in the core specification.

There I will differ.

The fact that we didn't call them XPATH expressions in the first place,
(for the xpath functions) means that we are stuck at the bottom and we
can't seem to raise the bar to a more stringent type that may be checked
before evaluation. (which is the argument above).

Having it specified as an XPATH expression in the Request will raise the
bar a bit, and you can always sink to the lower string implementation
without a problem, (and let the thing die in the XPATH evaluation).

Cheers,
-Polar

> seth
>