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


Thanks Paul,

Did you already update the wiki with the required cast? I couldn't find it.

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.)

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. ;-)

Best regards,
Erik

On 2009-12-07 04:35, Tyson, Paul H wrote:
> Erik,
>
> I revised the wiki page to correct the example, and to show native xpath
> replacements for all XACML xpath-* functions.  These are correct in
> theory, but I don't have a testbed to test them.
>
> I was not aware that AttributeSelector specified the use of an xpath
> constructor function for its return value, so I was expecting "effective
> boolean value".  As you said in your latest, the problem is easily fixed
> by casting within xpath.  This is only a minor problem for people (like
> me) who are accustomed to XSLT's "Principle of least surprise" approach.
>
> As far as I can tell (without testing), the only syntax difference for
> Xpath 1.0 is in the node equality test.  This is noted in the wiki page.
>
> Regards,
> --Paul
>
>    
>> -----Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>> Sent: Sunday, December 06, 2009 08:48
>> To: Tyson, Paul H
>> Cc: xacml
>> Subject: Re: [xacml] Paul's xpath proposal
>>
>> Hi Paul,
>>
>> I gave it some more thought. Your example can probably be
>> fixed by casting the xpath boolean value type into a string
>> representation within the xpath expression. But I don't know
>> the syntax myself, and I am not sure it is available in xpath 1.
>>
>> Best regards,
>> Erik
>>
>>
>>      
> <snip>
>    



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