The trouble with XQuery

XQuery was designed by the World Wide Web Consortium as an easier to use alternative to XSLT. In this it succeeded, but most of the power of XSLT was lost.

My critiques of the XQuery specification on this page came just a little late, just a few months after XQuery became a proposed recommendation in november 2006 and there were only a few implementations. But then my critique is of a fundamental nature, rather then just a few changes here and then.

Actually I started this research after reading the first XQuery Working Drafts in 2003. While I had been working with XSLT and could see some things done better in XQuery, it was clear to me that XQuery was not going in the direction I wanted XML manipulation to go. Even though I didn't have the foggiest notion what it was I wanted then.

But let's start with the good things of XQuery:

The code is readable (in contrast to XSLT code).
It is easier to learn than XSLT.
It is designed bottom up as a multi XML-input tool.
Combining data from different XML sources is easy.

As is easy to see XQuery is designed as a reaction to XSLT by a group of database guys who were missing some of their favourite tools in XSLT.

I am a database guy as well and I do miss those tools in XSLT as well. However, I still miss a lot of tools in XQuery:

The basic syntax cannot be expanded.
I do not like the workaround for outer-joins.
The model is strictly single output.
The mathematical power of XSLT is lost.
The code is long and reuse frustates the readability.
Commenting is as bad as in XSLT.

In short I think they threw the baby out with the water.

XQuery does not have the XSLT ability to:

Make a whole site using a single source file.
Change just one thing (e.g. remove <font> tags).
To analyse the input.

Also it is no longer easy to use the language itself to generate a new source file in the same language.