W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: XPath and find/findAll methods

From: Henri Sivonen <hsivonen@iki.fi>
Date: Tue, 29 Nov 2011 18:09:22 +0200
Message-ID: <CAJQvAucfrg_pe7D-isnjx4ivyzDTsVAzYz9eterB0Cb+i_tpnQ@mail.gmail.com>
To: liam@w3.org
Cc: public-webapps@w3.org
On Tue, Nov 29, 2011 at 7:33 AM, Liam R E Quin <liam@w3.org> wrote:
> (2) Not a dead end
> XSLT 1 and XPath 1 are not "evolutionary dead ends" although it's true
> that neither the xt nor the libxml2 library supports XSLT 2 and XPath 2.
> There's some support (along with XQuery) in the Qt libraries, and also
> in C++ with XQilla and Zorba.  There are maybe 50 implementations of
> XPath 2 and/or XQuery 2 that I've encountered.  XQuery 3.0 and XPath 3.0
> are about to go to Last Call, we hope, and XSLT 3.0 to follow next year.
> The work is very much active and alive.

Sure, XPath and XSLT keep being developed. What I meant by
evolutionary dead end is that the XPath 1.0-compatibile evolutionary
path has been relegated to a separate mode instead of XPath 2.0 and
newer being compatible by design. So the new development you cite
happens with Compatibility Mode set to false. To remain compatible
with existing content, browsers would presumably have to live in the
Compatibility Mode set to true world, which would mean browsers living
on a forked evolutionary path that isn't the primary interest of the
WGs working on the evolution.

I don't have enough data about existing XPath-using Web content to
know how badly the Web would break if browsers started interpreting
existing XPath (1.x) expressions as XPath 2.x expression with
Compatibility Mode set to false, but the fact that the WG felt that it
needed to define a compatibility mode suggests that the WG itself
believed the changes to be breaking ones.

>    /html/body/div/p[@id = /html/head/link[@rel = 'me']/@src]/strong

This example depends on unprefixed name expressions matching the
(X)HTML namespace when tested against an element and no namespace when
tested against attributes. And that trick only works with (X)HTML

Selectors have the advantage that they wildcard the namespace by
default, so it's feasible to define APIs that don't even have
namespace binding mechanisms.

Henri Sivonen
Received on Tuesday, 29 November 2011 16:10:00 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC