Project

Profile

Help

Support #1832

closed

op:is-same-node() fails to throw error when empty sequence passed as parameter

Added by Lars Huttar over 11 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Low
Assignee:
-
Category:
User error
Sprint/Milestone:
-
Start date:
2013-06-25
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

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

test-is.xsl (789 Bytes) test-is.xsl Lars Huttar, 2013-06-25 16:35
Actions #1

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.

Actions #2

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

Actions #3

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.

Actions #4

Updated by Michael Kay over 11 years ago

  • Category changed from XPath conformance to User error
  • Status changed from In Progress to Resolved
Actions #5

Updated by O'Neil Delpratt over 10 years ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF