Jonathan Robie’s XQuery Blog: 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.
I’m quickly catching up with some blog reading, and came across this gem from Jonathan Robie.
If you are someone who wonders “Should I use XSLT or XQuery?” or you are someone who is commonly asked this question, then add this entry to your favorites.
In fact, make it your home page. :)
I've generally found that the divisions are fairly obvious. I use XQuery when dealing with moving non-XML data (such as database content) into a reasonable XML form (and yes, Mark, I really do have a use for XQuery on occasion ;-). XSLT I use for general transformations. Indeed, I'm beginning to realize that XQuery may actually end up becoming the new Stored Procedures, as they provide a mechanism for data abstraction from various RDBMSs store.
>> and yes, Mark, I really do have a use for XQuery on occasion
Dr. Michael Kay wrote on XMLDEV:
"As far as the choice between XSLT and XQuery is concerned, I'm tending to sum it up like this:
(a) if your data is in a database, you need XQuery
(b) copying a document with small changes is much easier in XSLT
(c) extracting a small amount of information from your documents is easier in XQuery
(d) XQuery is easier to learn and is simpler for small jobs
(e) XQuery is better for highly-structured data, XSLT for loosely-structured documents
(f) for large applications involving reusable components, use XSLT
I'd encourage you to learn both, since 80% of what you learn will be applicable to both languages."
Yep. While I probably have no need to state what should be obvious, I 100% agree with ALL of this. XQuery and XSLT go hand in hand. XQuery solves a TON of issues in regards to how to access stored data in a way that doesn't require a hacked together approach using the document function with a REST-styled HTTP GET request, which for all intents and purposes is nothing more than the hack that it represents.
Okay, that ones fairly obvious... But this is not always the case, thus the clarification. There are times the simplicity offered up by a supposed hack, can in fact show the elegance of using a simple solution for a task that was once thought to require more than it did to gain the desired result. Thats DEFINITELY NOT the case with using this particular hack as what is generally returned is a glob of generic XML in which you then have to parse through, find the pieces you want, and discard the rest which can in many cases result in significant bandwidth cost, speaking in both over-0the-wire and processor terms.
XQuery saves a TON of bandwidth in this sense, returning only the data that you need, sometimes in a pre-transformed format, sometimes not (depends on the situation at hand, obviously). But either way, if you want to gain the advantages of a simple, yet powerful data access language, while minimizing the amount of overall code necessary to accomplish an overall transformation task using reusable, pre-defined output templates, then you need both.
Of course, then the debate between XSLT 1.0, XSLT 2.0, and/or EXSLT 1.0 (spec in progress) comes into the picture, which is obviously another topic all together. Without digging deep into an area that I would prefer not to dig to deep into, I will say this:
Use XSLT 1.0 intead of XSLT 2.0?
You're kidding, right? Yeah, K, cuz' thats not gonna happen... Once you've crossed the line from the 1.0 to 2.0 mentality, you're cooked. Theres no uncooking you at this stage... 2.0 now OWNS your little Masochistic self, which for us Masochistic-types, is a good thing. ;)
I do think it will be interesting to see the result of the work going on in the EXSLT world who's spec has been headed up by John L. Clark, Uche, Jim Fuller, with support from various folks such as Sylvain and the other folks at 4Suite and the community at large. It seems for folks who prefer dynamic languages such as Python will probably gravitate more in this direction than they will the 2.0 direction as the dynamic mindset is of primary influence into the EXSLT 1.0 specification development.
Will be interesting to see the result for sure! :D