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-dev] xpath, urn:oasis:names:tc:xacml:1.0:resource:xpath

Hi Niko,

The TC is preparing the core errata for publication and the pointer
I gave you is the current state, and the issues from this email should
be discussed and included as appropriate, and I agree that B.6 and
A.3.15 leave one a bit unsure as to what is the real situation, and all
this should be part of resolving the issue.

On your xpath questions, I am not an expert on xpath and do not
know the answer about xpointer, but will also bring this to attention
of TC, and the terminology re: "root" I was just using loosely, so
you are probably correct that "context" is the correct term as
to where the xpath starts within the document.


Niko Matsakis wrote:
> 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 
> occasion.
>> 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.
> regards,
> Niko Matsakis
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-dev-help@lists.oasis-open.org

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