This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The following incompatibility should be documented in Appendix I.1 In XPath 1.0, the expression -x|y parsed as -(x|y), and returned the negation of the numeric value of the first node in the union of x and y. In XPath 2.0, this expression parses as (-x)|y. For example, given the untyped input element <foo y="3"/> as the context node, the expression -@x|@y in XPath 1.0 returns -3, but in XPath 2.0 (without static type checking) returns 3.
Furthermore, rules 8 and 9 in appendix I.2 appear misplaced or incomplete. Rule 8 reads: <quote> 8. The rules for converting numbers to strings have changed. These may affect the way numbers are displayed in the output of a stylesheet. For numbers whose absolute value is in the range 1E-6 to 1E+6, the result should be the same, but outside this range, scientific format is used for non-integral xs:float and xs:double values. </quote> This statement is equally true when XPath 1.0 compatibility mode is true, and should therefore be in Appendix I.1 Rule 9 reads: <quote> The rules for converting strings to numbers have changed. In addition to the changes that apply when XPath 1.0 compatibility mode is true, when compatibility mode is false the strings Infinity and -Infinity are no longer recognized as representations of positive and negative infinity. Note also that while the number function continues to convert all unrecognized strings to NaN, operations that cast a string to a number react to such strings with a dynamic error. </quote> This clearly invites the inference that when XPath 1.0 compatibility mode is true, the strings Infinity and -Infinity are accepted as representations of positive and negative infinity. However, there is no normative statement anywhere that supports this inference.
The corrected text is in erratum XP.E2
According to comment #0, "-@x|@y in XPath 1.0 returns -3, but in XPath 2.0 (without static type checking) returns 3." However, I believe that in XPath 2.0, if compatibility mode is true, evaluating the expression -@x|@y, given the indicated context node, results in a type error. According to section 3.4,[1] in compatibility mode, "If the atomized operand is an empty sequence, the result of the arithmetic expression is the xs:double value NaN." So the result of -@x is NaN in this case. According to 3.3.3,[2] "If an operand of union, intersect, or except contains an item that is not a node, a type error is raised [err:XPTY0004]," so -@x|@y results in a type error. If compatibility mode is false, -@x will result in an empty sequence, so I believe the result of -@x|@y will be a sequence containing the attribute node "y", rather than the value 3.
My apologies! I ommitted the references from comment #3 [1] http://www.w3.org/TR/xpath20/#id-arithmetic [2] http://www.w3.org/TR/xpath20/#combining_seq
After correcting the error noted in comment #3, the change will be published in XPath erratum XP.E2