http://norman.walsh.name/2004/05/19/xsltxquery 7 87 2004-05-19T08:25:00-04:00 $Date: 2005-09-11 10:27:02 -0400 (Sun, 11 Sep 2005) $ Norman Walsh 2004 Norman Walsh 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¢. Blaise Pascal 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. 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.