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 3733 - [XPath] reorder rules in Node Comparisons
Summary: [XPath] reorder rules in Node Comparisons
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 2.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Don Chamberlin
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 3699
  Show dependency treegraph
 
Reported: 2006-09-15 19:39 UTC by Andrew Eisenberg
Modified: 2006-09-19 17:40 UTC (History)
1 user (show)

See Also:


Attachments

Description Andrew Eisenberg 2006-09-15 19:39:14 UTC
In http://www.w3.org/Bugs/Public/show_bug.cgi?id=3699, it was suggested that bullets 2 and 3 be swapped in section 3.5.3, Node Comparisons. This section now reads as follows:

"The result of a node comparison is defined by the following rules:

1. The operands of a node comparison are evaluated in implementation-dependent order.

2. Each operand must be either a single node or an empty sequence; otherwise a type error is raised [err:XPTY0004].

3. If either operand is an empty sequence, the result of the comparison is an empty sequence, and the implementation need not evaluate the other operand or apply the operator. However, an implementation may choose to evaluate the other operand in order to determine whether it raises an error.

4. ..."

As written, the commentor thought that we might intend that "() is 100" be required to raise XPTY0004.
Comment 1 Don Chamberlin 2006-09-19 17:39:57 UTC
Andrew,
On Sept. 16, 2006, the Query and XSLT working groups discussed this issue and agreed with your suggestion to reverse the order of Rules 2 and 3 in Section 3.5.3, Node Comparisons. This change will enable an early exit from node comparisons if either operand is an empty sequence (preserving consistency with value comparisons.) Since you were present during the discussion, I am marking this bug report as Fixed and Closed.
Regards,
Don Chamberlin (for the Query and XSLT working groups)