xacml — archive

RE: [xacml] xpath-expression datatype

From: Polar Humenn <[email protected]>
To: [email protected]
Date: Thu, 26 Aug 2004 20:28:00 -0000

 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: Polar Humenn <[email protected]>
To: 'XACML' <[email protected]>
Date: Thu, 26 Aug 2004 16:25:32 -0400 (EDT)







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






Follow-Ups:

RE: [xacml] xpath-expression datatype
From: Seth Proctor <[email protected]>



References:

RE: [xacml] xpath-expression datatype
From: Tim Moses <[email protected]>
RE: [xacml] xpath-expression datatype
From: Seth Proctor <[email protected]>
RE: [xacml] xpath-expression datatype
From: Polar Humenn <[email protected]>
RE: [xacml] xpath-expression datatype
From: Seth Proctor <[email protected]>
RE: [xacml] xpath-expression datatype
From: Polar Humenn <[email protected]>
RE: [xacml] xpath-expression datatype
From: Seth Proctor <[email protected]>






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]