For boolean, number and string types, the XPath recommedation has a simple and straightforward idea of what consititutes equality -
The = comparison will be true if and only if the objects are equal; the != comparison will be true if and only if the objects are not equal. Numbers are compared for equality according to IEEE 754 [IEEE 754]. Two booleans are equal if either both are true or both are false. Two strings are equal if and only if they consist of the same sequence of UCS characters.
For node-sets, things are a little different.
If both objects to be compared are node-sets, then the comparison will be true if and only if there is a node in the first node-set and a node in the second node-set such that the result of performing the comparison on the string-values of the two nodes is true.Two node-sets are equal, then, if any node in one set has the same string-value as any other node in the second set. The nodes in question don't have to be the same node (ie having the same position in the same instance), just have the same value. The node-sets themselves could contain different numbers of nodes, and so on.
Comparisons of node-sets and string or number values are defined similarly
If one object to be compared is a node-set and the other is a number, then the comparison will be true if and only if there is a node in the node-set such that the result of performing the comparison on the number to be compared and on the result of converting the string-value of that node to a number using the number function is true. If one object to be compared is a node-set and the other is a string, then the comparison will be true if and only if there is a node in the node-set such that the result of performing the comparison on the string-value of the node and the other string is true.If any single node in the set matches the comparision value, then the node-set and the value are equal.
Only the comparision of a node-set and a boolean value is what you might inituitively expect
If one object to be compared is a node-set and the other is a boolean, then the comparison will be true if and only if the result of performing the comparison on the boolean and on the result of converting the node-set to a boolean using the boolean function is true.
Despite these unusual looking definitions of equality, when you actually use them in an XPath, the "right" thing seems to happen. Consider
/root/child[@attr = 'theoneIwant']Here
@attrselects a node-set, which will be empty, or contain a single attribute named
attr. If this attribute the value
theoneIwantthen the predicate is true.
/root/child[grandchild = 'theoneIwant']We read this as selecting those
childwhich have a
grandchildnode contain the text
theoneIwant. It's a straightforward XPath, and nothing unusual. The
childnodes might have multiple
grandchildnodes. Without the above definition for node-set and string equality, we couldn't construct the appropriate XPath so concisely. I haven't thought about this in great depth, but if equality were not defined as it is, it might not be possible at all withouth defining some other mechanism (like a function say). As it is, the odd sounded definition leads to "natural looking" XPaths.
The reason I've been thinking about this is, as you might have guessed, because I've been working on node-set equality this morning.