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