Subject: [xsl] () eq () vs () = () From: Andrew Welch <andrew.j.welch@xxxxxxxxx> Date: Fri, 30 Sep 2011 10:43:39 +0100 |
I've recently found out (over on the saxon list) that: () eq () returns the empty sequence, but () = () returns false. What is the benefit of returning the empty sequence over false... when would I want that? It seems like an unecessary gotcha to me... similar to xs:boolean('0') vs fn:boolean('0') Also, this is from the xpath 2.0 spec: "Consider the expression //part[color eq "Red"]. An implementation might choose to rewrite this expression as //part[color = "Red"][color eq "Red"]. The implementation might then process the expression as follows: First process the "=" predicate by probing an index on parts by color to quickly find all the parts that have a Red color; then process the "eq" predicate by checking each of these parts to make sure it has only a single color" ...which makes me wonder bother with using 'eq' at all. I wouldn't use it to ensure there is only one of something, that would be done elsewhere... I always thought it allowed the comparison to be optimised behind the scenes, but that suggests otherwise. thanks -- Andrew Welch http://andrewjwelch.com
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] jar in stylesheets, Michael Kay | Thread | Re: [xsl] () eq () vs () = (), Stefan Krause |
Re: [xsl] Re: XPath that returns no, Michel Hendriksen | Date | Re: [xsl] () eq () vs () = (), Stefan Krause |
Month |