This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1826 - Editorial: op:union/op:intersect defined in F&O, but error handling in XPath 2.0
Summary: Editorial: op:union/op:intersect defined in F&O, but error handling in XPath 2.0
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Ashok Malhotra
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2005-07-28 16:23 UTC by Frans Englich
Modified: 2005-09-29 12:51 UTC (History)
0 users

See Also:


Description Frans Englich 2005-07-28 16:23:44 UTC

This is maybe intentional, but I find it a bit confusing that error handling for
op:union, op:intersect and op:intersect is defined in XPath 2.0, "If an operand
of union, intersect, or except contains an item that is not a node, a type error
is raised [err:XPTY0004].", while their definitions are in F & O "15.3 Equals,
Union, Intersection and Except."

Should the error handling specification be moved from XPath20 to F & O?

Comment 1 Michael Kay 2005-07-28 17:52:58 UTC
You're not the only one that's confused by the way the operator specifications
are split between the language book and the F+O book, but there is some method
in the madness: in general operators are polymorphic, and the language book
describes the logic that decides which of the various (non-polymorphic)
functions needs to be despatched. In this case there is no suitable function to
handle non-node-operands, so a type error is raised during the despatch process,
not by the function itself.

Michael Kay (personal response)
Comment 2 Ashok Malhotra 2005-07-28 18:38:54 UTC
Shall we close this based on Michael Kay's explanation of the situation?
Comment 3 Frans Englich 2005-07-28 18:42:11 UTC
Yes, I wouldn't object at least.

Comment 4 Ashok Malhotra 2005-07-28 18:49:40 UTC
Closed with approval of the commentor.