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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-dev message

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

Subject: Re: [xacml-dev] xpath, urn:oasis:names:tc:xacml:1.0:resource:xpath

First, thank you for your quick response!

> You are correct that resource:xpath needs to be added to XACML 2.0.  
> This
> was identified as an errata:
>     http://lists.oasis-open.org/archives/xacml/200702/msg00001.html

Ok, that's good to know.  I did indeed check the errata list before  
posting, but I only saw an errata for the SAML

However, let me pose one additional question: in xacml 1.0, for  
example, the resource:xpath attribute in the example context has the  
value xmlns(md=...) xpointer(/md:record/md:patient/md:patientDoB).   
This is clearly not an xpath expression, but an xpointer one.  Does  
this mean that the XACML processor must also support xpointer?

I see that the XACML specifications (both 1.0 and 2.0) seem to use  
XPath/Xpointer interchangeably, even writing "XPath/Xpointer" on  

> On the second part of your question, I think the answer is in  
> section B.6 p 129:
> 5036 This attribute identifies the resource to which access is  
> requested. If an <xacml
> 5037 context:ResourceContent> element is provided, then the  
> resource to which access is
> 5038 requested SHALL be all or a portion of the resource supplied  
> in the <xacml
> 5039 context:ResourceContent> element.
> 5040 urn:oasis:names:tc:xacml:1.0:resource:resource-id
> I interpret this to mean that the presence of this attribute  
> combined with the
> presence of the ResourceContent element makes that element the default
> root xpath from which other xpaths are derived.

While I agree that this interpretation helps the examples to make  
sense, I would not say it is exactly crystal clear from the text you  
quoted.  Furthermore, the text in the xpath section (A.3.15) clearly  
states "The <Request> element is the context node for every XPath  
expression," which seems like a contradiction.  So, if your  
interpretation is correct, I think an errata is definitely warranted.

I would also say that making the Resource element the "root" of the  
xpath evaluation  --- as opposed to the context node --- is a fairly  
involved transformation, as it involves creating (at least  
conceptually) a separate XML document from the <RequestContent>  
element [along with any inherited namespaces, etc].  Otherwise, as I  
read the specification, the xpath expression normally ranges over the  
complete request document.


Niko Matsakis

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