XQuery 1.0 or XSLT 2.0?

Volume 7, Issue 87; 19 May 2004; last modified 08 Oct 2010

I’ve seen a number of recent blogs about XPath 2.0, XSLT 2.0, XQuery 1.0, and their relation to each other. My 2¢.

The multitude which is not brought to act as a unity, is confusion. That unity which has not its origin in the multitude is tyranny.

Blaise Pascal

I’ve seen a number of recent blogs about XPath 2.0, XSLT 2.0, XQuery 1.0, and their relation to each other. Much of the current discussion seems to have its genesis in the revelation that the next version of .NET will have support for XQuery 1.0 and not XPath 2.0 or XSLT 2.0. I haven’t chased down all the references to be absolutely sure because I don’t care very much about .NET.

Some of the reasons I’ve seen are entirely reasonable. It seems to boil down to, “we asked the customers what they wanted and we’re giving it to them.” Who can argue with that? But some of the reasons expressed are misleading or just plain wrong.

Dare Obasanjo argues that “XQuery is strongly and statically typed while XPath 2.0 is weakly and dynamically typed.” What’s not clear from his post is that he is comparing XQuery 1.0 to XPath 2.0 in backwards compatibility mode (Michael Rys did provide a clarification). That’s an odd comparison to make. XPath 2.0 needs a backwards compatibility mode so that it stands some chance of doing the right thing when used in the context of an XSLT 1.0 stylesheet, but that’s not the expected mode for long-term use.

XPath 2.0 and XQuery 1.0 have the same semantics, defined by XQuery 1.0 and XPath 2.0 Formal Semantics. In fact, the XPath 2.0 and XQuery 1.0 specifications are generated from a common source document. They are largely the same specification. This makes arguments about the difficulty of implementing both XPath 2.0 and XQuery 1.0 seem a little odd, though it’s certainly true that it’s a design choice and design choices can have a profound impact on implementation costs.

Some other arguments are about syntax. Yeah, there are people who will prefer the SQL-like syntax. I’m not one of them. But Arpan Desai says, within an argument about syntax, that “the programming paradigm [of XSLT] is quite hostile to anybody who isn't a fan of LISP.” That’s a more inflamatory tone than I would have used, but as an argument for XQuery it seems like a non sequitur to me. They have the same paradigm. My guess is that folks just think it’s simpler because it doesn’t have angle brackets.

I have built systems that rely on the fact that I can generate XSLT with XSLT and that I can query XSLT with XSLT. I’m surprised that the folks doing XQuery don’t see this as an important feature, but I understand the trade-off of choosing a syntax that’s more familiar. (Yes, before someone points it out, I’m aware that XSLT doesn’t let you query easily into XPath expressions and that something like XQueryX does allow it. I just like the 80/20 cut of XSLT a little better.)

The funniest arguments are the ones that imply that XQuery is a competitor in the same problem space as XSLT, that users will use XQuery instead of XSLT. I say that’s funny because there are so many problems that you simply cannot solve with XQuery. If your data is regular and especially if it’s all stored in a database already so that your XQuery implementation can run really fast, then XQuery absolutely makes sense, but didn’t the database folks already have a query language? Nevermind. If your customers don’t need to solve the kinds of problems for which XSLT was designed, or if you want to sell them some sort of proprietary system to solve them, then implementing XSLT 2.0 probably doesn’t make sense.

If you want to transform documents that aren’t regular, especially documents that have a lot of mixed content, XSLT is clearly the right answer. I’ll wager dinner at your favorite restaurant that XQuery cannot be used to implement the functionality of the DocBook XSLT Stylesheets. (You produce the XQuery that does the job, I buy you dinner.)

The only serious competition for XSLT 2.0 is XSLT 1.0. And it is serious. Biting off XSLT 2.0 is going to be a non-trivial effort for folks with significant XSLT stylesheets. My impression at the moment is that it’s probably worth it and over time, people will migrate to 2.0 for the additional features that it provides (grouping, regular expressions, character maps, and standard patterns for transforming result trees and producing multiple output documents, for example).

I’m certainly starting to think seriously about making the switch.


Hi Norm

My colleagues are aware that XPath 2.0 and XQuery 1.0 are very closely related. The point about XPath 2.0 is that it lacks certain capabilities that need to be provided by a host environment. Since XQuery provides XPath 2.0 plus more, there is currently no reason to implement XPath 2.0.

And I agree with you on XSLT 1.0 being the biggest competitor to XSLT 2.0 (and not XQuery 1.0). That's what my post is basically saying at the moment...

—Posted by Michael Rys on 19 May 2004 @ 02:54 UTC #

How can I use XPATH 2.0   string functions from within an XSL file, and then apply this XSL file to a well formed XML document to see the result in IE.

When calling Most of XPATH 2.0 string functions from an XSL file, IE gives me an error saying that, for example, replace() is unknown function .. .



—Posted by Wael on 01 Sep 2005 @ 09:21 UTC #

good points. i will say that, as someone committed to XSLT/XPath and to the .NET runtime, i ignored most of the blather about XQuery. I also was annoyed when MSFT made the commitment to XQuery over XSLT 2.0. IHMO, XQuery is really 'back-sliding' on the whole extensible model. it seems that MSFT's embrace of XQuery has more to do with thier long term strategy for C# (google c-omega for more on this) than any agruments about the merit or future of XSLT/XPath.

for now, i will be looking for a .NET plug-in for XSLT 2.0/Xpath 2.0 and will have to wait for MSFT to bring thier XML support up to speed again.

—Posted by mamund on 07 Sep 2005 @ 04:31 UTC #