W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > November 2007

Re: XPath version

From: Innovimax SARL <innovimax@gmail.com>
Date: Wed, 14 Nov 2007 18:27:27 +0100
Message-ID: <546c6c1c0711140927g6e43442fi3075ea47f6167c6b@mail.gmail.com>
To: "Norman Walsh" <ndw@nwalsh.com>
Cc: public-xml-processing-model-wg@w3.org

On Nov 14, 2007 3:08 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> / Innovimax SARL <innovimax@gmail.com> was heard to say:
> |> 6. In the scope of xpath-version=1.0, if the processor uses XPath 2.0,
> |> it SHOULD evaluate the expression using XPath 1.0 backwards
> |> compatibility mode. If it does not support that mode, it simply
> |> attempts to evaluate the expression as XPath 2.0 and throws a dynamic
> |> error if it doesn't work.
> |
> | This one worries me the most : sometime XPath 2.0 processor IS PERFECTLY
> | able to evaluate the expression, but the result is wrong.
> We could say that an implementation MUST support backwards compatibility,
> I suppose.
> Do you have some expressions in mind that you think might really turn up
> in pipelines?

Yeh that's easy

In I.2 Incompatibilities when Compatibility Mode is false

2. In XPath 1.0, the < and > operators, when applied to two strings,
attempted to convert both the strings to numbers and then made a
numeric comparison between the results. In XPath 2.0, these operators
perform a string comparison using the default collating sequence. (If
either value is numeric, however, the results are compatible with
XPath 1.0)

-> Let's say version comparison

3. When an empty node-set is supplied as an argument to a function or
operator that expects a number, the value is no longer converted
implicitly to NaN. The XPath 1.0 behavior can always be restored by
using the number function to perform an explicit conversion.

-> This one is trickier and far less usual

5. The rules for comparing a node-set to a boolean have changed. In
XPath 1.0, an expression such as $node-set = true() was evaluated by
converting the node-set to a boolean and then performing a boolean
comparison: so this expression would return true if $node-set was
non-empty. In XPath 2.0, this expression is handled in the same way as
other comparisons between a sequence and a singleton: it is true if
$node-set contains at least one node whose value, after atomization
and conversion to a boolean using the casting rules, is true. This
means that if $node-set is empty, the result under XPath 2.0 will be
false regardless of the value of the boolean operand, and regardless
of which operator is used. If $node-set is non-empty, then in most
cases the comparison with a boolean is likely to fail, giving a
dynamic error. But if a node has the value "0", "1", "true", or
"false", evaluation of the expression may succeed.

-> This is far far more current (the fact is that I'm still making
mistake in XSLT 2.0 because of that rule)

10. Many operations in XPath 2.0 produce an empty sequence as their
result when one of the arguments or operands is an empty sequence.
Where the operation expects a string, an empty sequence is usually
considered equivalent to a zero-length string, which is compatible
with the XPath 1.0 behavior. Where the operation expects a number,
however, the result is not the same. For example, if @width returns an
empty sequence, then in XPath 1.0 the result of @width+1 was NaN,
while with XPath 2.0 it is (). This has the effect that a filter
expression such as item[@width+1 != 2] will select items having no
width attribute under XPath 1.0, and will not select them under XPath

-> I can see use of this one

12. In XPath 1.0, it was defined that with an expression of the form A
and B, B would not be evaluated if A was false. Similarly in the case
of A or B, B would not be evaluated if A was true. This is no longer
guaranteed with XPath 2.0: the implementation is free to evaluate the
two operands in either order or in parallel. This change has been made
to give more scope for optimization in situations where XPath
expressions are evaluated against large data collections supported by
indexes. Implementations may choose to retain backwards compatibility
in this area, but they are not obliged to do so.

-> This one is more here for warning and could be removed


Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
RCS Paris 488.018.631
SARL au capital de 10.000 
Received on Wednesday, 14 November 2007 17:27:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:54 GMT