W3C home > Mailing lists > Public > www-xpath-comments@w3.org > January to March 2002

Incompatibilities XPath 1.0 vs 2.0?

From: Jeni Tennison <jeni@jenitennison.com>
Date: Wed, 2 Jan 2002 18:17:38 -0500 (EST)
Message-ID: <15312549204.20020102221835@jenitennison.com>
To: www-xpath-comments@w3.org
CC: xsl-list@lists.mulberrytech.com
Hi,

I *think* that there are some problems with backwards compatibility
that aren't listed in Appendix D of the XPath 2.0 WD.

Section 2.3.3.1 Predicates:

 "If the value of the predicate expression is one simple value of a
  numeric type, the value is rounded to an integer using the rules of
  the round function, and the predicate truth value is true if and
  only if the resulting integer is equal to the value of the context
  position."

I haven't got access to the XPath 1.0 errata at the moment, but at
least some of the implementations (Saxon and Xalan) seem to round down
(floor) numeric predicates rather than rounding them (round).

---

Also, I think the definition for predicates changes what happens when
the predicate expression evaluates to a string. In XPath 1.0, the
string is converted to a boolean (an empty string to false, a string
with characters to true), and this is used. For example:

  text()[normalize-space()]

returns text nodes whose value contains non-whitespace characters. It
appears from the description in Section 2.3.3.1 that this expression
will now raise an error, since it is not an empty sequence, not a
numeric type, not boolean, and not a sequence of nodes.

---

On a similar note, Section 2.7 Logical Expressions doesn't seem to
handle situations where the expressions are other than nodes or
boolean values. What about if one of the operands is a string or a
number? No mention is made of the required types of the comparison or
how other values are cast to boolean values, which presumably they
should be.

---

In Appendix A.3, it says:

 "A space may be significant after "/" or "//", in order to
  distinguish, for instance "//div" and "// div foo" without lookahead."

This was not the case in XPath 1.0 (where you could do / div div 3
quite happily if you felt so inclined). (I don't think there's a
problem with "//" - that's not a valid path expression anyway.)

Cheers,

Jeni
---
Jeni Tennison
http://www.jenitennison.com/
Received on Thursday, 3 January 2002 07:45:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 3 October 2007 16:05:54 GMT