OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] xpath-expression datatype



I don't care about the example. Let the example show the capabilities of
the language, whatever the capabilities are.

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.

Of course, it doesn't have to be, since we allow dynamic typing as well.
But this gives us the language the capbility to, in that example (I'm
looking at draft 12, so I'm not sure I've got the right line number).

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.

Cheers,
-Polar


On Thu, 26 Aug 2004, Seth Proctor wrote:

>
> On Thu, 2004-08-26 at 15:31, Polar Humenn wrote:
> > Now, I wonder, why the change to "#string". I know it's the fact that they
> > *are* strings.  However, they are special strings, i.e. all XPATH
> > expressions are strings, but NOT all strings are XPATH expressions.
> >
> > Is there any special reason to make them strings? Such as you want to
> > concatenate them or something?
>
> For all the reasons discussed in this thread already. We're only talking
> about one string, in one example in the specification. I'd like that
> example to be meaningful in the scope of the funcationality defined in
> the spec. The only functions in the spec that could use that argument
> accept strings as input.
>
> Let's be clear here. I'm not talking about "them" plural. I'm not
> talking about changing standardard funtionality. I'm not trying to
> remove meaning from anything in the specification. I'm merely suggesting
> how to make a single example more meaningful to those who are looking at
> it for the first time. Specifically, I'm suggesting that the datatype
> used at line 1072 be string.
>
>
> seth
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]