- From: Innovimax SARL <innovimax@gmail.com>
- Date: Wed, 14 Nov 2007 18:27:27 +0100
- 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 2.0. -> 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 Mohamed -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
Received on Wednesday, 14 November 2007 17:27:40 UTC