XSLT vs. XQuery
About once a week, someone asks me a question about the relationship between XSLT and XQuery - is XQuery a better language than XSLT? when would I use each language in preference to the other? is there really any fundamental reason that XSLT can't be optimized for large data stores just like XQuery? which language is better for writing really large applications?
Here are some of the differences between the two languages.
-
XQuery was designed to be optimizable for large data stores. XSLT was designed for the kinds of transformations used in stylesheets - it has come to be used much more broadly, but nobody has done a good job of translating it to efficient SQL or implementing it to work efficiently on native XML databases. You can argue whether the same kind of thing could be done in XSLT, but realistically, it's unlikely that anyone will ever do that.
-
XQuery is typically easier to use for things that feel like "queries"; XSLT is easier for things that feel like transformations, especially formatting-oriented transformations on recursive data structures like those found in documents.
-
XQuery has a keyword-oriented syntax that is more like other commonly used languages than the XML-based syntax of XSLT. I don't think this is a big deal, but some programmers seem to have a hard time getting past XSLT syntax.
I have heard Mike Kay suggest that XSLT is much better for designing very large queries, and heard Jason Hunter suggest that these kinds of queries are much easier in XQuery. Personally, I am more comfortable writing very large XQueries than very large stylesheets, but I've also written a lot more large queries than large stylesheets.
There are XSLT zealots and XQuery zealots who insist that one of these two languages is best. I use both languages, and like both languages. But XQuery is clearly the language that was designed for large data stores, or for the kind of implementation that translates a query to other query languages such as SQL.
By the way, Mike Kay's useful XTech 2005 paper examines these questions in much more depth.
No comments:
Post a Comment