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 5445 - [XPath] Undocumented incompatibility with compatibility mode "true" for general comparison involving boolean
Summary: [XPath] Undocumented incompatibility with compatibility mode "true" for gener...
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 2.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows XP
: P5 normal
Target Milestone: ---
Assignee: Don Chamberlin
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL: http://www.w3.org/TR/xpath20/#id-gene...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-31 20:25 UTC by Henry Zongaro
Modified: 2008-03-11 14:44 UTC (History)
0 users

See Also:

Attachments

Description Henry Zongaro 2008-01-31 20:25:20 UTC 
According to section 3.5.2 of XPath 2.0,[1] if "XPath 1.0 compatibility mode is true and... either operand is a single atomic value that is an instance of xs:boolean, then the other operand is converted to xs:boolean by taking its effective boolean value."

Thus, with compatibility mode true, the result of evaluating the expression "true() > number('0.5')" is false, while the result of "true() = number('0.5')" would be true.

According to section 3.4 of XPath 1.0,[2] if one operand of an = or != operator is xs:boolean and the other is not a node-set, the other operand is converted to xs:boolean; if the operator is <, <=, > or >=, and neither operand is a node-set, both are converted to numbers.  Thus, in XPath 1.0 the result of evaluating "true() > number('0.5')" is true, and the result of "true() = number('0.5')" is also true.

The list of incompatibilities with compatibility mode true in section I.1 of XPath 2.0,[3] as modified by erratum XP.E2,[4] does not mention this incompatibility.

[1] http://www.w3.org/TR/xpath20/#id-general-comparisons
[2] http://www.w3.org/TR/xpath#booleans
[3] http://www.w3.org/TR/xpath20/#id-incompat-in-true-mode
[4] http://www.w3.org/XML/2007/qt-errata/xpath20-errata.html#E2
Comment 1 Henry Zongaro 2008-01-31 21:07:07 UTC 
I did some research into the history of the current wording of the effect of XPath 1.0 compatibility mode on general comparison operators.  This text first appeared in the October 2004 working draft of XPath 2.0 [5] in response to a public comment.[6]  That decision was made at the Sept. 9, 2004 meeting of the XSL WG.[7]  (I haven't tracked down the corresponding XQuery WG or joint meeting decision.)

It's not clear from the discussion of the original issue whether the working groups noted the fact that the changes would introduce a new incompatibility for "true() > number('0.5')".  Assuming that really was the intent of the working groups, a new item should be added to section I.1 of XPath 2.0:

  "7. If one operand in a general comparison is a single atomic value of type
      xs:boolean, the other operand is converted to xs:boolean when XPath 1.0
      compatibility mode is set to true.  In XPath 1.0, if neither operand of a
      comparison operation using the <, <=, > or >= operator was a node set,
      both operands were converted to a number.  The result of the expression
      <code>true() &gt; number('0.5')</code> is true in XPath 1.0, and it is
      and false in XPath 2.0 processor when compatibility mode is set to true."

Alternatively, if the working groups did not intend to introduce this incompatibility, they might consider restricting the first item in the first numbered list in section 3.5.2 of XPath 2.0 to apply only in the case of the = and != general comparison operators.

[5] http://www.w3.org/TR/2004/WD-xpath20-20041029/#id-general-comparisons
[6] http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0298.html
[7] http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Sep/0012.html (Members only)
Comment 2 Michael Kay 2008-03-11 14:19:57 UTC 
At the joint meeting on 2008-03-04 it was decided to leave the normative specification unchanged and to draft an editorial erratum to document the incompatibility. The erratum (E6) adds a new item to appendix I.1 as proposed in comment #1.

I have drafted and checked in the erratum (though there may be some technical work needed to merge it with E2). I am marking the bug report as FIXED and since Henry Zongaro was present at the discussion, as CLOSED.
Comment 3 Henry Zongaro 2008-03-11 14:44:11 UTC 
Just for the record, I didn't attend the joint telecon of 2008-03-04, but the resolution of the bug is nonetheless acceptable to me.