[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Paul's xpath proposal
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]