Asking about what is better XQuery or XSLT is like asking which car is better Ferrari or Bentley. The answer is: "It depends"! What are you looking for, how are going to use it, who are you going to use it with etc.
To me XSLT and XQuery in the XML world are like the left and the right hand - some tasks are better, quicker and easier to reach when implemented with XSLT and other are better, quicker and esier when written in XQuery. There is never a simple "right" answer. Are you are writing one off transformation? How often you are going to change it and the most important question - which of these languages comes more natural to you and makes you more productive.
I used to write almost everything in XSLT using XQiery just as a glue layer between the requests, the database and the XSLT. Recently because of time constraints I switched to XQuery completely and I am very pleased with the quick results. I still use XSLT here and there and I am convinced XSLT is a place to lay very good foundations for XQuery.
I think one of strengths of XSLT is its simple mechanism for extensibility when using pattern matching. All you need to do is to add an include file with additional pattens and you are done. You can repeat this as many times as you need without ever changing the original XSLT file. You can even generate a list of include files as you need them, even in run time. XSLT is perfect for creating highly reusable libraries.
Using the typeswitch in XQuery is completely the opposite. The only way to extend the original functionality is to add MANUALLY all new cases into the ORIGINAL file. When we work with predictable, stable, slow changing data, like documentation XQuery it perfectly OK. But if you do data driven applications there the code adapts to the data then XQuery is still behind XSLT. Having said that I have to add that using util:function and util:call can find same way around and mimic the XSLT way. My point is the extensibility in XQuery does not come out of the box as with XSLT.
Switching same functionality from one language to another could be very educational and brings a lot of fun. If somebody wants to toy with it and there is a need I say why not, go for it. There is always room to make things better, faster and easier to maintain.
I hope this helps.
On 9 April 2010 21:30, Wolfgang Meier <email@example.com>
> I dont think that doing basic document to document conversion inI think this is a misunderstanding. A simple document to document
> XQuery makes any sense, XSLT is easier to develop this in and more
transformation can sometimes be even more intuitive in XQuery ;-) All
you need to learn is typeswitch plus a few function calls. I'm using
this more and more in my own code (for example, see
Done in the right way, the control flow in an XQuery can be easier to
understand and maintain than the template matching mechanism of XSLT.
Don't misunderstand me. I like XSLT. I use a pretty large XSLT to
generate multi-volume, 1000 pages PDFs from a set of TEI documents
stored in eXist. The processing only takes a few minutes, despite the
thousands of small queries it sends to eXist, e.g. to assemble
bibliographies and SVG graphics. However, this also shows the
limitations of XSLT: it becomes quite tricky once you need to
integrate data from many sources. Native XSLT support in eXist would
overcome this limit. It's on the way, but there's still a lot of work
left to be done.
Anyway, my main argument for using more XQuery for the website is that
you want to keep the examples as simple as possible and reduce the
number of standards new users have to learn.