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] Paul's xpath proposal


Hi Erik,

See inline.

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com] 
> Sent: Monday, December 07, 2009 07:06
> To: Tyson, Paul H
> Cc: xacml
> Subject: Re: [xacml] Paul's xpath proposal
> 
> Thanks Paul,
> 
> Did you already update the wiki with the required cast? I 
> couldn't find it.
>

Are you seeing the latest at
http://wiki.oasis-open.org/xacml/XpathDiscussion?

In the example, I use count() in the RequestContextPath, which will
return an integer that fn:boolean() will use to construct a boolean
return value.
 
> Another question. In the examples the xpath you are matching 
> against is always a single location step. Would it still work 
> with a path with multiple location steps? I get a feeling 
> that there will be a difference. Can you do it without an 
> absolute xpath anywhere? (Absolute xpaths cause problems for 
> optimization because the span the request context and may 
> also be a security risk since the <Request> can be embedded 
> in a transport document.)

I need to see some examples of this.  I can't picture it.

I assume implementations will construct separate DOM objects for each
Content element in the request, rather than try to apply xpath
operations to a Request DOM.  If the implementation does the latter, it
would have to "fix up" xpath expressions somehow, which could be tricky.

From the policy writer's perspective, the request is just a wrapper for
the Content, so his idea of absolute xpath expressions are those that
begin at the root of <Content>.  (Maybe this is underspecified in XACML:
since Content can contain multiple children, you must infer an anonymous
"root" container for these children to correspond to a leading "/" in
xpath.)

> 
> Also, I am uncertain about the usabilitiy aspect. the xpath 
> node match functions are perhaps easier to understand than 
> clever xpath trickery. I am not sure yet where my opinion is 
> on that one. ;-)

I guess we could leave them in as syntactic sugar, and define them in
terms of native xpath.  For me (and probably for others with xslt
experience), the XACML xpath-* functions are confusing.

Regards,
--Paul

<snip>


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