This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Hello, 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? Cheers, Frans
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)
Shall we close this based on Michael Kay's explanation of the situation?
Yes, I wouldn't object at least. Frans
Closed with approval of the commentor.