Cette page n'est pas disponible en français. Veuillez-nous en excuser.

ABIS Infor - 2011-06

XQuery vs. XSLT: battle or coexistence?

Sandy Schillebeeckx (ABIS) - 23 May 2011


XQuery and XSLT are both designed to query and manipulate XML documents. There is an enormous amount of overlap among the features and capabilities of these two languages. So when are you going to use what?

What's in a name?

At a first glance you could say:

XQuery = XML Query Language

XSLT = XML Stylesheet Language for Transformations

Obvious, don't you think? XQuery is for querying, and XSLT is for transforming documents. In origin, this actually was the case.

When XSLT1.0 came out in 1999, it was the only way to reach both goals.

Let's consider the following XML document, containing Person information:

    <Function>TRAINING CONSULT</Function>
        <CompanyName>ABIS N.V.</CompanyName>
    <Name><FirstName>ANN</FirstName><LastName>DE KEYSER</LastName></Name>
      <CompanyName>ABIS N.V.</CompanyName>

I want to extract the first name and function elements of all employees of ABIS N.V., sorted on first name. Oh, by the way, the result should be an XML document again, but replace "Person" by "AbisPerson".


This is how it be done using an XSLT stylesheet:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="PersonList">
      <xsl:for-each select="Person[Company/CompanyName='ABIS N.V.']">
        <xsl:sort select="Name/FirstName"/>
        <AbisPerson> <xsl:copy-of select="Name/FirstName | Function"/></AbisPerson>

Works fine. The structure is a bit tedious. You have to get used to this way of "stylesheet programming". But once you get the hang of it, you can do a lot with it. By using the PUSH technique (instead of PULL which was used here), you can even modularize your code and much much more.


But couldn't this be done in an 'easier' way? Something more query-like? In 2007, XQuery1.0 was released to serve this purpose, and my question can now be solved like this:

<PersonList> {
   for $pers in doc("personList.xml")/PersonList/Person
   where $pers/Company/CompanyName = 'ABIS N.V.'
   order by $pers/Name/FirstName
   return <AbisPerson> {$pers/Name/FirstName}  {$pers/Function} </AbisPerson>
} </PersonList>

As you can see, XQuery is much more descriptive. Usability studies have shown that XQuery is easier to learn than XSLT, especially for users with previous experience of database languages such as SQL. The FLWOR expressions indeed remind you of SQL.

Especially when you start combining ('joining') documents, the solution becomes a lot simpler.

Actually, did you notice that I'm not just performing a query, but that I'm also doing a transformation (renaming of the Person element)? This indicates that with XQuery you can do more than just querying. But does that mean that XSLT is superfluous?

XSLT or XQuery?

Both 'languages' can indeed serve the same purpose. Even more since XSLT2.0 was released in 2007. They are now both fully based on XPath2.0.

Will XQuery replace XSLT, or can they live together in peaceful coexistence?

For the moment, XSLT is still more widespread. Partially since it has proven its capabilities over the years. But XQuery is starting to move in. People see the strengths of the language, the simplicity.

For query-like questions, XQuery is indeed a lot more concise and faster, and certainly worth a try. Even for XSLT diehards.

But for bigger applications, where you can gain from modular programming, when you have an application that involves making small changes to a document (for example, deleting all the FUNCTION elements) or when the whole document structure has to be transformed, XSLT is still more powerful.

So may they both live together happily ever after.