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