You're talking about two completely different languages: The reason XQuery is easier for people with a background in SQL is because -- like SQL -- XQuery is designed from a "I would like this data. Please give it to me so I can do something with it." perspective whereas XSLT is designed from a "Here is some data. Please give me something else in return." perspective.

XSLT has never nor will it ever be a query language in the same way XQuery has never nor will it ever be a transformation language. A lot of folks tend to think of XQuery as a transformation language, but that's more from lack of experience than anything else. That's not to discredit XQuery: It's a fantastic tool that serves a very needed purpose. And so is XSLT, serving a very needed but *different* purpose.

@David,

I disagree that XQuery is not a transformation language. It is both a transformation and a query language. For example, BEA Aqualogic ESB (Enterprise Service Bus) and Apache ServiceMix use XQuery for message transformation.

However, certain transformation tasks are better handled by XSLT.

John Smith

The differences between XSLT 2.0 and XQuery aren't that great, so anyone familiar with one of them shouldn't take too long to be comfortable with the other - knowing both well isn't a problem and there's no need to focus on one to the detriment of the other.

The big difference between them is XSLT's recursive descent processing model (which is perfect for processing XML but hard to grasp especially with the implicit default templates...) perhaps that's the reason why XQuery is easier to learn.

Your comparison is slightly strange as you give the example of variable references being confusing on XSLT, but they work exactly the same in XQuery. XQuery is, apart from surface syntax differences, essentially just XSLT without xsl:apply-templates.
While XSLT apply-templates might seem confusing at first, in XQuery as it isn't available then you need to be more not less familiar with functional programming techniques and coding of recursive functions.

So it's not surprising that XQuery is easier to teach than XSLT as it is essentially XSLT without the features that make using it as a database query language hard/inefficient. It's a strictly smaller language than XSLT (the mapping can be implemented see xq2xsl for one possible implementation of that mapping).
If you know XQuery and want to learn XSLT you need to learn about template matching, if you know XSLT and want to learn XQuery, you just need to learn a new syntax.

David

@Joh Smith,

>> "I disagree that XQuery is not a transformation language. It is both a transformation and a query language."

You can disagree all you want, but you first need to properly understand what I view a transformation language to be. There are plenty of variations on the definition of transform, but here's one of my favorite,

>> "To change into a different form, substance, or state: convert, metamorphose, mutate, transfigure, translate, transmogrify, transmute, transpose, transubstantiate. See change/persist."

Much like SQL, XQuery is built upon a foundation of taking a given data source -- in this case XML -- and asking it to provide for you a subset of the original source based on a given set of query parameters. Your mistake in the assertion that XQuery is also a transformation language is the assumption that a transformation from one state to another allows the ability for the intermediary to pick and choose which pieces of a given data source it wants to work with to then take the resulting pieces and turn it into something else.

But as per the above definition, that's not what a transformation is about.

>> "convert, metamorphose, mutate, transfigure, translate, transmogrify, transmute, transpose, transubstantiate. See change/persist."

The power that is XSLT is the ability to assume nothing as far as the state of the data source is concerned. That's not your concern. Your concern is simply to take a given XML data source and -- regardless of its current state -- transform it into something else, whatever that something else might be. And here in lies the difference between XQuery and XSLT:

XSLT is based on a foundation of templates which use a rules-based matching mechanism to determine which template should process which XML element. It's *VERY* dynamic, *VERY* adaptive, and therefore *VERY* transformative by its vary nature. And this is the key foundation to understanding the difference between XQuery and XSLT: XQuery doesn't adapt. It's a MUST UNDERSTAND language where as XSLT is a MAY UNDERSTAND language, which is why they tend to be so aggressive in their Passive-Aggressive campaigns against each other.

* XQuery is *VERY* aggressive: "Give me this! And I'll do whatever I damn well please with it, thank you very much."

* XSLT is *VERY* passive: "Hmmm... You know what. No thanks. You're not my type."

Of course some will argue that putting Passive and Aggressive together is just asking for trouble, recommending medication and then getting the hell out of the way before they get hurt by any of the side effects. Unfortunately there really isn't any medication for Passive-Aggressive "disorder": Passive-Aggressive is just a disgruntled employees way of trying to place a label on what -- in reality -- is just members of society being human.

But that's another argument for another day. ;-)

Gosh, David P, this seems have hit some tender point! I've rarely heard XQuery and XSLT spoken of with such passion! But you overstate the point. As David C says, the essential difference is the pattern matching in XSLT which supports push-style transformations, but I would guess that a lot of XSLT is written in pull-style using for loops and the like in which mode it is is no more 'passive' or 'aggressive' than XQuery. In both cases, the XPath expressions assume as little as nessary about the input and construct just the same output. Certainly, some kinds of transformation are easier to write in push-style XSLT where recursive functions are needed in XQuery.

As for difficulty of learning, I teach both and I have to say I start with pull-style XSLT rather than XQuery. That's partly because XSLT is XML and if I'm concentrating on teaching XML, it is synergistic to use an XML language for scripting as well. Some students then get to make the discovery that, ahah, I can write XSLT to process XSLT too! I then move on the push-style XSLT, introducing pattern-matching to replace for loops. It's very easy to get into a tangle if you start with pattern-matching however because you really need to understand how that pattern matching is being done in some detail.

I also teach XQuery but later for web application development, leveraging the integration of XQuery with an XML database (eXist of course!). To contrast XQuery with SQL, I use the comparison based on the old EMP-DEPT-SALGRADE example which is in the XQuery Wikibook[1].

For both languages, the switch from imperative to functional is a difficult transition for students from an object-oriented background, but it is a satisfying step once made.

Finally, I wonder if anyone has done an analysis of XSLT scripts in the wild of the proportion of push and pull constructs used?

[1] http://en.wikibooks.org/wiki/XQuery/XQuery_from_SQL

"Finally, I wonder if anyone has done an analysis of XSLT scripts in the wild of the proportion of push and pull constructs used?"

The "wild" consists largely of OO devs who dabble in XSLT, struggle with it, and end up with a mess of call-templates and escaping out to the host language for trivial tasks.

I see attempts to structure XSLT like OO languages - one template per file, ridiculous imports trees and "frameworks" that are meant to be ingenious but just become a hindrance as the complexity grows.

Anyway, mini-rant over, push vs pull depends on how closely the output structure mirrors the input structure - if they're similar then push can used, if they're nothing alike pull is used.

You should still use template matching even when pull processing to open your stylesheet up for overriding - for-each really should only be used to change the context node, such as a wrapper for xsl:key in 1.0 (which isn't needed for 2.0) It's very rare that you _need_ to use for-each.

Regarding teaching XSLT, in my experience jumping straight in with template matching yields best results. Starting with fill-in-the-blanks stylesheets and for-each gives students a chance to make wrong assumptions that have to be un-learnt later. Hammer home xsl:apply-templates and the fact you're building a result tree and people seem to arrive at the "a-ha" moment without much effort.

@David,

>>You can disagree all you want, but you first need to properly understand what I view a transformation language to be.

You can try to change the definition of transformation like Bill Clinton tried to change the definition of sex. But for all practical purpose, if you give me XML that complies with schema 1 and want me to produce an XML that complies with schema 2, or you want me to produce HTML or XSL FO output, then I can do all that with XQuery.

In 2005 I wrote a dissertation about the usability of XML query languages (http://igitur-archive.library.uu.nl/dissertations/2005-1018-200002/index.htm).

As a part of this study, I taught students both XQuery and XSLT and measured there performance with these languages. In my experience (both research and practical), XQuery is way easier to learn than XSLT. However, in my opinion it is easier to write complex transformations/queries in XSLT 2.0 than in XQuery.

I also noticed that although XSLT and XQuery have different design goals, they are used for similar purposes in practice. Except that XSLT is not very often used to query XML databases.

@John Smith,

>> But for all practical purpose, if you give me XML that complies with schema 1 and want me to produce an XML that complies with schema 2, or you want me to produce HTML or XSL FO output, then I can do all that with XQuery.

Again, you seem to be missing the point. The fact that I can take some XML in XQuery and generate XML isn't what a transformation is all about. As specified above, XQuery is a MUST UNDERSTAND language. It doesn't adapt: You have to know what your input is going to be. If it's different, you're out of luck. XSLT is a MAY UNDERSTAND language. Because of the built-in template mechanism, I can build a transformation file that can adapt to whatever is thrown its direction. Something as simple as,

<xsl:template match="*">
<copy-of select="."/>
</xsl:template>

... ensures that if I don't understand something it still gets copied in the output document, and something as simple as,

<xsl:template match="*"/>

... ensures that if I don't understand something it doesn't. XQuery doesn't allow for such things because it lacks the fundamental feature that allows this to work: Templates.

Don't get me wrong: XQuery is fantastic! But its design is for a different purpose, a purpose that XSLT isn't very good at: Querying XML. Both are necessary tools to get the most out of your XML development.

@David P,

The W3C XQuery Requirements document at (http://www.w3.org/TR/xquery-requirements/) states:

"3.4.11 Structural Transformation
Queries MUST be able to transform XML structures and MUST be able to create new structures.
green status Status: this requirement has been met."

I hope that helps.

This problem might demonstrate David P's point: take any XML input and suppress all elements that aren't known, or perhaps aren't in a given namespace.

In XSLT this is easy, in XQuery it's harder and without Updates it's impossible (isn't it XQuery'ers??)

@Andrew W,

I think anyone who has worked with both XSLT and Xquery will agree that certain transformation tasks are easier to handle with XSLT. However, denying or ignoring the transformation capabilities of XQuery could lead to missed opportunities in application design (in terms of performance for example, if you have a really fast XML database, you don't want to hand over the query result to an XSLT engine for transformation).

Also the vast majority of developers out there who deal with data-centric XML (as opposed to document-centric XML) will prefer XQuery for transformation. That's why most ESB applications use XQuery as opposed to XSLT for transformation.

My view is the two languages will work together - XSLT will fire off various queries and then process the results, especially when generating markup... which is the majority of cases.

Then if some bright spark could make the XSLT work directly against the database... ;0)

@david
It seems to me there are two problems with your argument. First that you have redefined transformation to some narrower sense which is a 'permissive' transformation - in the same sense that Schematron is permissive (everything not forbidden is allowed) and XMLSchema is restrictive (everything not allowed is forbidden) - which would rule out most useful transformations. In my experience permissive transformations are most useful for schema evolution i.e from schema S to the variant S'; permissive transformations are little use for transformations from schema A to a different schema B.

Secondly that you assume that permissive transformations can't be written in XQuery. But consider the following recursive function:

(: return a deep copy of the element and all sub elements :)
declare function local:copy($element as element()) as element() {
element {node-name($element)}
{$element/@*,
for $child in $element/node()
return
if ($child instance of element())
then local:copy($child)
else $child
}
};

which can be adapted to pass or filter nodes of any required characteristic. Since it requires editing this function to add conditionals and/or typeswitch to express filter conditions, this approach is not as composable as the rule-based templates in XSLT are, but that's not the same as saying there is fundamental computational distinction. Lately, we have switched to using XQuery even for schema changes because the ease of composability is outweighed by the simplicity of using a single language.

@Chris,

So you're saying,

(: return a deep copy of the element and all sub elements :)
declare function local:copy($element as element()) as element() {
element {node-name($element)}
{$element/@*,
for $child in $element/node()
return
if ($child instance of element())
then local:copy($child)
else $child
}
};

is just as easy as saying,

<xsl:template match="*">
<copy-of select="."/>
</xsl:template>

?

Chris: Come on, now: Let's not attempt to discredit the strength's of XSLT just because we can hack our way into partially mimicking it's strengths in XQuery. We can hack our way into the strengths of XQuery with XSLT. Does that mean we should?

@david
On the contrary, I implied that it -was- easier in XSLT - rules can be simply added in XSLT allowing much easier composition. I'm only saying that your characterisation of XQuery is exaggerated since it is quite possible (but not as convenient) to write permissive transformations.

@Chris,

>> I'm only saying that your characterisation of XQuery is exaggerated since it is quite possible (but not as convenient) to write permissive transformations.

Thanks for the clarification! I do agree that XQuery can be used to mimic some of the MAY UNDERSTAND capabilities of XSLT, the problem I have with this is that this then requires that people understand the purpose of this functionality in the first place. If they understand the purpose then they've already overcome the difficulty of learning XSLT, and if they've already overcome that difficulty then they are more likely to use XSLT than they would be otherwise. In other words: Once you've had the XSLT (and Lisp, Scheme, etc..) "Aha!" moment you find programming in it so much fun that you tend to look for ways to use it in places it wouldn't normally be used. For me, anyway, XQuery isn't nearly as much fun to program in for the simple fact that it lacks the feature that makes programming in XSLT so powerful once you get it: Templates.

Of course, I do enjoy programming in XQuery. And the fact that there was zero learning curve given my foundation in XSLT certainly helped me acquire a taste for it faster than I would have otherwise. I just don't see it becoming "go to" XML processing language anytime soon.

s/see it becoming "go to"/see it becoming my "go to"/