Support #1832
closedop:is-same-node() fails to throw error when empty sequence passed as parameter
0%
Description
In Saxon-PE 9.4.0.4, when I evaluate the XPath expression @/* is /..@, I get an empty sequence.
According to the XPath 2.0 spec at http://www.w3.org/TR/xpath-functions/#func-is-same-node,
a) Each of op:is-same-node()'s arguments (operands) must be a single node. If one of them is a sequence of more than one node, an error is thrown (Saxon does this correctly). However, when one of them is an empty sequence, Saxon should throw an error but doesn't.
b) op:is-same-node() is supposed to return a value of type xs:bool (if it returns at all). In the case of @/* is /..@, it returns an empty sequence.
Files
Updated by Michael Kay over 11 years ago
The "is" operator maps to op:is-same-node() only in cases where the operands are non-empty. The spec for "is" is here:
http://www.w3.org/TR/xpath20/#id-node-comparisons
and says:
If either operand is an empty sequence, the result of the comparison is an empty sequence.
In fact, I think you've found a buglet in the spec, because the op:is-same-node() function is an orphan; the specification of "is" does not depend on it, and it is not referenced in the operator mapping table in the XPath language spec.
Updated by Michael Kay over 11 years ago
- Tracker changed from Bug to Support
- Status changed from New to In Progress
Correction; it IS referenced in the operator mapping table, but the specification of NodeComp does not appeal to the operator mapping table. I've raised a bug against the spec:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22456
However, this is only in the interests of clarification and elimination of redundancy. It is definitely the case that the intent is that ($A is ()) should return (), and any clarification to the spec will confirm this (hundreds of W3C test cases depend on it!)
Updated by Lars Huttar over 11 years ago
Thanks for explaining this. I had skimmed over 'backs up the "is" operator on nodes', not realizing there was a non-trivial relationship between the function and the operator; and had not looked at the operator mapping table.
Updated by Michael Kay over 11 years ago
- Category changed from XPath conformance to User error
- Status changed from In Progress to Resolved
Updated by O'Neil Delpratt over 10 years ago
- Status changed from Resolved to Closed
Please register to edit this issue