Shared Components

The good news is that if you’ve learned one of these two languages, you’re well on your way toward learning the other. XQuery and XSLT are developed together, with compatibility between them in mind. Among the components they share are:

The data model

Both languages use the data model described in “The XQuery Data Model”. They have the same concepts of sequences, atomic values, nodes, function items, maps, and arrays. Namespaces are handled identically. In addition, they share the same type system and relationship to XML Schema.

XPath

XQuery is essentially a superset of XPath. XSLT makes use of XPath expressions in many areas, from the expressions used to match templates to the instructions that copy nodes from input documents.

Built-in functions and operators

All the built-in functions described in Appendix A can be used in both XQuery and XSLT, with the same results. All the operators, such as comparison and arithmetic operators, yield identical values in both languages. XSLT has some additional built-in functions, such as current and document, that are not part of XQuery and therefore not covered in this book.

Equivalent Components

In addition to the components they directly share, XQuery and XSLT also have some features that are highly analogous in the two languages; they just use a different syntax. XSLT instructions relating to flow control (e.g., xsl:if and xsl:for-each) have direct equivalents in XQuery (conditional and FLWOR expressions). Literal result elements in XSLT are analogous to direct XML constructors in XQuery, while the use of xsl:element and xsl:attribute in XSLT is like using computed constructors in XQuery. Some of these commonly used features are listed in Table 27-1.

Differences

The most obvious difference between XQuery and XSLT is the syntax. A simple XQuery query might take the form:

<ul type="square">{
  for $prod in doc("catalog.xml")/catalog/product[@dept = 'ACC']
  order by $prod/name
  return <li>{data($prod/name)}</li>
}</ul>

The XSLT equivalent of this query is:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ul type="square">
      <xsl:for-each select="catalog/product[@dept = 'ACC']">
        <xsl:sort select="name"/>
        <li><xsl:value-of select="name"/></li>
      </xsl:for-each>
    </ul>
  </xsl:template>
</xsl:stylesheet>

XQuery is somewhat less verbose, and many people find it less cumbersome than using the XML syntax of XSLT. Users who know SQL find XQuery familiar and intuitive. Its terseness also makes it more convenient to embed in program code than XSLT.

On the other hand, XSLT stylesheets use XML syntax, which means that they can be easily parsed and/or created by standard XML tools. This is convenient for the dynamic generation of stylesheets.

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="catalog">
    <ul>
      <xsl:for-each select="product">
        <li>Product #: <xsl:value-of select="number"/></li>
        <li>Product name: <xsl:value-of select="name"/></li>
      </xsl:for-each>
    </ul>
  </xsl:template>
</xsl:stylesheet>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="catalog">
    <ul>
      <xsl:apply-templates/>
    </ul>
  </xsl:template>
  <xsl:template match="product">
    <xsl:apply-templates/>
  </xsl:template>
  <xsl:template match="number">
    <li>Product #: <xsl:value-of select="."/></li>
  </xsl:template>
  <xsl:template match="name">
    <li>Product name: <xsl:value-of select="."/></li>
  </xsl:template>
  <xsl:template match="node()"/>
</xsl:stylesheet>

<p>It was a <b>dark</b> and <i>stormy</i> night.</p>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="p">
    <para><xsl:apply-templates/></para>
  </xsl:template>
  <xsl:template match="b">
    <Strong><xsl:apply-templates/></Strong>
  </xsl:template>
  <xsl:template match="i">
    <Italics><xsl:apply-templates/></Italics>
  </xsl:template>
</xsl:stylesheet>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="p">
    <para>
      <xsl:for-each select="node()">
        <xsl:choose>
          <xsl:when test="self::text()">
             <xsl:value-of select="."/>
          </xsl:when>
          <xsl:when test="self::b">
            <Strong><xsl:value-of select="."/></Strong>
          </xsl:when>
          <xsl:when test="self::i">
            <Italics><xsl:value-of select="."/></Italics>
          </xsl:when>
        </xsl:choose>
      </xsl:for-each>
    </para>
  </xsl:template>
</xsl:stylesheet>

for $catalog in doc("catalog.xml")/catalog
return <ul>{for $prod in $catalog/product
            return (<li>Product #: {data($prod/number)}</li>,
                    <li>Product name: {data($prod/name)}</li> )
       }</ul>

declare function local:apply-templates($nodes as node()*) as node()* {
  for $node in $nodes
  return typeswitch ($node)
        case element(p) return local:p-template($node)
        case element(b) return local:b-template($node)
        case element(i) return local:i-template($node)
        case element() return local:apply-templates($node/(@*|node()))
        default return $node
};
declare function local:p-template($node as node()) as node()* {
   <para>{local:apply-templates($node/(@*|node()))}</para>
};
declare function local:b-template($node as node()) as node()* {
   <Strong>{local:apply-templates($node/(@*|node()))}</Strong>
};
declare function local:i-template($node as node()) as node()* {
   <Italics>{local:apply-templates($node/(@*|node()))}</Italics>
};
local:apply-templates(doc("p.xml")/p)

Data Model

The XPath 1.0 data model has the concept of a node-set, which is a set of nodes that are always in document order. In XQuery/XPath 2.0+, there is the similar concept of a sequence. However, sequences differ in that they are ordered (not necessarily in document order), and they can contain duplicates. Another difference is that sequences can contain atomic values and function items as well as nodes.

Root nodes in XPath 1.0 have been renamed document nodes in XQuery/XPath 2.0+. Namespace nodes (and the namespace axis) are now deprecated in XPath 2.0 and later, and not at all accessible in XQuery. They have been replaced by two functions that provide information about the namespaces in scope: in-scope-prefixes and namespace-uri-for-prefix.

New Expressions

XPath 2.0 and later versions encompass a lot more than just paths. Some of the new kinds of expressions include:

• Conditional expressions (if-then-else)

• for expressions, which are a subset of XQuery FLWORs that have only one for or one let clause and a return clause

• Quantified expressions (some/every-satisfies)

• Ordered sequence constructors (($x, $y))

• Additional operators to combine sequences (intersect, except)

• Node comparison operators (is, <<, >>)

• Arrays and maps (starting in version 3.1)

These new expressions are all part of XPath itself, not just XQuery.

Path Expressions

If you already use XPath 1.0, the path expressions in XQuery should be familiar. The basic syntax and meaning of node tests and predicates is the same. The set of axes is almost the same, except that the namespace:: axis is not available.

There are some additional enhancements to path expressions. One is the ability to have the last step in a path return atomic values rather than nodes. So, for example:

doc("catalog.xml")//product/name/substring(., 1, 5)

will return the first five characters of each product name, resulting in a sequence of four string atomic values. This makes it really easy to do things that were tough in XPath 1.0; for example, summing over the product of price and quantity becomes:

sum(//item/(@price * @qty))

Another improvement is that it is now possible to have any expression as a step. You can take advantage of all the newly added kinds of expressions described in the previous section. It also allows you to create navigational functions that are very useful as steps, for example:

customer/prod:orders-for-customer(.)/product-code

Function Conversion Rules

In XPath 1.0, if you call a function that is expecting a single value, and pass it a sequence of multiple values, it simply takes the first value and discards the others. For example:

substring(doc("catalog.xml")//product/name, 1, 5)

In this case, there are four product nodes. XPath 1.0 just takes the name of the first one and returns Fleec. In XQuery/XPath 2.0+, type error XPTY0004 is raised.

XQuery is strongly typed, while XPath 1.0 is not. In XPath 1.0, if you pass a value to a function that is of a different type—for example, a number to a function expecting a string, or vice versa—the value is cast automatically. In XQuery/XPath 2.0+, type error XPTY0004 is raised. For example:

substring(12345678, 1, 4)

attempts to take the substring of a number. It will return 1234 in XPath 1.0, and raise type error XPTY0004 in XQuery/XPath 2.0+. Instead, you would need to explicitly convert the value into a string, as in:

substring(string(12345678), 1, 4)

Arithmetic and Comparison Expressions

In XPath 1.0, performing an arithmetic operation on a “missing” value results in the value NaN. In XQuery/XPath 2.0+, it returns the empty sequence—for example, the expression:

catalog/foo * 2

Similar to the function conversion rules, in XPath 1.0, an arithmetic expression will take the first value of a sequence and discard the rest. In XQuery/XPath 2.0+, it raises type error XPTY0004.

In XPath 1.0, operands of all types are automatically converted to numbers for arithmetic operations. In XQuery/XPath 2.0+, the operands must be untyped or numeric.

It is possible in XQuery/XPath 2.0+ to compare non-numeric values such as strings by using the operators <, <=, >, and >=. In XPath 1.0, this was not supported. By default, XQuery/XPath 2.0+ treats untyped operands of a comparison like strings, whereas they were treated as numbers in XPath 1.0. This is a significant compatibility risk, because the results of the comparison will be different if, for example, you are comparing <price>29.99</price> to <price>100.00</price>. XPath 1.0 would say that the first price is less than the second, while XQuery/XPath 2.0+ (in the absence of a schema that says they are numeric) would say that the second price is less, because its string value is lower.

Built-in Functions

There are almost 200 built-in functions in XQuery/XPath 3.1, as compared to 27 in XPath 1.0. All the built-in functions from XPath 1.0 are also supported in XQuery/XPath 2.0+, with a couple of minor differences:

• Some XQuery/XPath 2.0+ function calls return the empty sequence, where in XPath 1.0 they would have returned a zero-length string. This is the case if the empty sequence is passed as the first argument to substring, substring-before, or substring-after.

• Some XQuery/XPath 2.0+ function calls return the empty sequence, where in XPath 1.0 they would have returned the value NaN. This is the case if the empty sequence is passed to round, floor, or ceiling.