- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 29 Nov 2011 18:09:22 +0200
- 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 nodes. 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 hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Tuesday, 29 November 2011 16:10:00 UTC