RE: [xacml] xpath-expression datatype

[Seth Proctor <Seth.Proctor@Sun.COM>]

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