- From: <bugzilla@wiggum.w3.org>
- Date: Thu, 31 Jan 2008 21:07:08 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5445 ------- Comment #1 from zongaro@ca.ibm.com 2008-01-31 21:07 ------- 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() > 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)
Received on Thursday, 31 January 2008 21:07:14 UTC