- From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
- Date: Sun, 25 Apr 2021 15:56:55 -0600
- To: Steven Pemberton <Steven.Pemberton@cwi.nl>
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, Alain Couthures <alain.couthures@agencexml.com>, public-xformsusers@w3.org
> On 23,Apr2021, at 4:16 AM, Steven Pemberton <Steven.Pemberton@cwi.nl> wrote: > > This sounds like a good plan. What is it exactly that fails with the comparisons? > Speaking in general (and not with respect to any particular comparisons in the test suite), first of all the behavior depends on whether the XPath 2.0 or 3.0 processor is operating in “compatibility mode” (which in hindsight ought perhaps to have been named “1.0 compatibility mode”). Many but not all of the incompatibilities (which are listed in appendices of XPath 2.0 and 3.0 and 3.1 for those who want a fuller account) relate to the elaboration of the type system in XPath 2.0. https://www.w3.org/TR/xpath20/#id-backwards-compatibility https://www.w3.org/TR/xpath-30/#id-backwards-compatibility https://www.w3.org/TR/xpath-31/#id-backwards-compatibility Some examples (all drawn from the XPath 2.0 spec): - In XPath 1.0, in any comparison using <, <=, or >= in which neither operand is a node set, both values are converted to numbers before comparison. In 2.0, even with compatibility mode on, in a comparison in which one operand is boolean, the other operand is converted to xs:boolean before comparison. So in 1.0, the comparison true() > number(‘0.5’) is converted to 1 > 0.5 and evaluates to true; in 2.0 with compatibility mode on, it converts to true() > true() and is false. - In 1.0, if a node set containing more than one node is given as the argument to a function that expects a single value, the first value is taken and the others silently discarded; this should feel familiar to any user of XForms. In XPath 2.0, a type error occurs. (Solution: add [1] to the expression.) - In 1.0, an expression applying > or < to two strings is evaluated by attempting to convert both arguments to numbers and then compare them; in 2.0 without compatibility mode they are compared as strings. (Alain Couthures has already given examples of this.) If one argument is already numeric, the 2.0 spec says results will be the same as in 1.0. - In 1.0, comparisons of number and boolean, number and string, or string and boolean were performed by converting one of the arguments to the type of the other. (Examples: 4 = true() is true, 4 = “+4” is false (“+4” becomes NaN), false = “false” is false (because “false” as a non-empty string has true as its effective boolean value). In XPath 2.0, these all produce type errors. - The addition of numeric types like xs:integer and xs:decimal means that arithmetic operations do not always produce the same result as they would if all values were first converted to IEEE floating-point numbers. - In 2.0, operations for which one argument is an empty sequence often produce an empty sequence as a result. In 1.0, the corresponding operations on empty node sets produced empty strings, or NaN, or what have you. If @width produces an empty node set in 1.0 / an empty sequence in 2.0, then @width + 1 will produce NaN and () (the empty sequence) respectively. So in 1.0, item[@width + 1 != 2] will produce a result including items with no ‘width’ attribute, but in 2.0 such items will not be part of the result. When a document has XSD types, either because it has been schema-validated or because there are xf:bind elements assigning types to specific nodes, the results can be different from those of XPath 1.0, but I won’t try the patience of the reader by giving any examples; look at the XPath spec if you want them. I hope this helps. Michael ******************************************** C. M. Sperberg-McQueen Black Mesa Technologies LLC cmsmcq@blackmesatech.com http://www.blackmesatech.com ********************************************
Received on Sunday, 25 April 2021 21:57:16 UTC