Support #1832: op:is-same-node() fails to throw error when empty sequence passed as parameter - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Support #1832

closed

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

Added by Lars Huttar about 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:

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

Copy link

Updated by Michael Kay about 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

Copy link

Updated by Michael Kay about 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

Copy link

Updated by Lars Huttar about 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

Copy link