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 22456 - [XP 3.0] Non-polymorphic operators
Summary: [XP 3.0] Non-polymorphic operators
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-25 15:46 UTC by Michael Kay
Modified: 2015-07-06 08:22 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2013-06-25 15:46:54 UTC
F+O contains function definitions corresponding to the operators "is", <<, >>, "union", "except" and "intersect". The operator mapping table also contains entries for these operators. However, the specification of the constructs that use these operators (for example NodeComp, UnionExpr) is complete in itself and makes no reference to the operator mapping table or to the functions in F+O. There is therefore a lack of clarity as to whether the function specifications carry any force.

This does not apply to value comparison, general comparison, and arithmetic operators, where the language specification explicitly appeals to the operator mapping table and the corresponding functions.

Background: A Saxon user asked why ($N << ()) returns empty, rather than a type error, given the specification of op:node-before(). F+O claims that op:node-before defines the semantics of the << operator. I couldn't point to a chain of argument that shows that op:is-node-before() is relevant to the semantics of ($A << $B) when both $A and $B are nodes, but is not relevant where either operand is an empty sequence.
Comment 1 Jonathan Robie 2013-07-02 15:58:37 UTC
The operator mapping table does not take things like atomization, etc. into account. These things are defined in XQuery / XPath.
 
DECIDED: Mike Kay will clarify that the operator mapping does not fully define the semantics of the operator, but only the mapping applied to values of particular types.
Comment 2 Michael Kay 2013-07-03 15:18:12 UTC
The WG noted the problem, but decided to make minimal changes to the spec given the current stage of development. The notes in F+O describing the operator mapping will be slightly reworded to indicate (in particular for << and >>) that the function defines the semantics of the operator only in the case where the supplied operands are nodes.
Comment 3 Michael Kay 2014-09-16 18:54:14 UTC
Reopening as a 3.1 problem. The specification of operators such as "<<" and ">>" in the XPath book makes no reference to the operator mapping table or to F+O, so we have two specifications of these operators and no statement as to how they relate.

Personally, I'd be very happy to get rid of them from F+O.
Comment 4 Michael Kay 2014-09-23 17:31:30 UTC
Decided that this is editorial (changes the way the language is defined, does not change hte language) and therefore can be considered during Last Call.
Comment 5 Michael Kay 2015-03-24 15:51:34 UTC
In message

https://lists.w3.org/Archives/Member/w3c-xsl-query/2015Mar/0042.html

I proposed:

This bug seems to have slipped off the radar, because it has been classified as "editorial". But I think it's too substantial to implement without consensus. Could we have it back on the agenda please?

The operators "is", <<, >>, "union" (= "|"), "except", "intersect", "to", and "," are defined in two places: in the language book, and in F+O. There is no statement as to which description is definitive. F+O claims that its descriptions define the semantics of the operators defined in the language book, but the language book contains no reference to the F+O definitions, other than a mention in the operator mapping table. The language book contains complete (though somewhat informal) free-standing definitions of the operators. The F+O description does not say how empty sequence is handled as an argument; this is explained only in the language book. None of these operators have any associated error conditions.

Unless anyone objects, I propose that we delete these 8 operators from F+O, and remove the corresponding 9 entries (plus "||") from the operator mapping table.

The WG accepted this proposal.
Comment 6 Michael Kay 2015-07-06 08:22:26 UTC
Confirmed that the change has been implemented.