Query 1 shows that the XQuery path expression language is very much like that used in XSLT. In fact, it even borrows the document() function from XSLT for selecting the root nodes of documents by URI.

Example 1. (Q1) In the second chapter of the document named "zoo.xml", find the figure(s) with caption "Tree Frogs".

document("zoo.xml")/chapter[2]//figure[caption = "Tree Frogs"]

document("zoo.xml")/chapter[2]//figure[caption = "Tree Frogs"]

Query 2 shows one of the extensions to the XPath syntax provided in the XQuery path expression language. This extension had its origin in XQL[5], which, when it was defined, was an extension not to XPath but to the "XSL pattern" syntax, XPath's predecessor. Apart from its conciseness in comparison to the XPath equivalent, it adds nothing.

document("zoo.xml")/chapter[RANGE 2 TO 5]//figure

document("zoo.xml")/chapter[position() >= 2 and position() <= 5]//figure

Query 3 introduces XQuery's syntax for dereferencing ID references which is provided as a replacement of XPath's id() function. Apart from its purportedly better readability, it too adds nothing. Note, however, that the -> syntax includes an implicit name test; it will return only those referenced elements that are named "fig", whereas id() will return all referenced elements, regardless of name. Thus, in the XSLT equivalents below, I've included an explicit name test on the self axis.

It's not clear in the XQuery draft whether the -> syntax will operate only on IDREF and IDREFS, or values of any type (as is the case with XPath).

 
document("zoo.xml")/chapter[title = "Frogs"]
   //figref/@refid->fig/caption

id(document("zoo.xml")/chapter[title = "Frogs"]//figref/@refid)[self::fig]/caption

Query 4 seeks to demonstrate the better readability of the -> syntax. In addition to the straight XPath equivalent, I've included an XPath version that uses a variable reference, in order to show that better readability can be attained without deviating from the XPath standard. Note that variable bindings are part of the XPath specification[4].

The XPath equivalents here are admittedly not as readable as the XQuery example, but that is primarily due to the inclusion of the [self::emp] predicate. The added value of an automatic name test for referenced elements is debatable. In any case, this functionality is already available in standard XPath.

 
/emp[rating = "Poor"]/@mgr->emp/@mgr->emp/name

id(id(/emp[rating = "Poor"]/@mgr)[self::emp]/@mgr)[self::emp]/name

Or, for better readability, use this:
id($poorEmpManagers/@mgr)[self::emp]/name

...in conjunction with a variable binding, shown here in XSLT:
<xsl:variable name="poorEmpManagers" select="id(/emp[rating = 'Poor']/@mgr)[self::emp]"/>

Query 5 demonstrates how namespace prefix mappings may be used with XQuery's path expression language. Note that this is perfectly compatible with XPath, whose evaluation context includes a set of namespace prefix mappings. XSLT's approach, for better or worse, is to use the in-scope XML namespace declarations as its set of mappings.

 
NAMESPACE abc = "www.abc.com/names"
NAMESPACE xyz = "www.xyz.com/names"
document("zoo.xml")//abc:tiger[xyz:*]

(Use the in-scope namespace declarations)
document("zoo.xml")//abc:tiger[xyz:*]

Query 6 shows that a default namespace can be defined for use in path expressions. Users of XSLT may find this particularly surprising, since in XSLT the default namespace is not used to evaluate XPath expressions.

NAMESPACE DEFAULT = "www.abc.com/names"
NAMESPACE xyz = "www.xyz.com/names"
document("zoo.xml")//tiger[xyz:*]

(A prefix must be used, when in a namespace) 
document("zoo.xml")//abc:tiger[xyz:*]

Query 7 introduces XQuery's "element constructor" mechanism for constructing arbitrary XML. Clearly, element constructors are much like XSLT's literal result elements. Likewise, inline variable references in XQuery are interpreted in almost the exact same way as XSLT's xsl:copy-of instruction in conjunction with a variable reference.

The XQuery syntax is not quite XML; it is only designed to look like XML. Readability is arguably easier to attain in XQuery, because it has more syntactic flexibility. Note, however, that XSLT, at least in this example, does a pretty good job of attaining readability, even within the confines of XML syntax (thanks in large part to attribute value templates).

 
<emp empid = $id>
   <name> $n </name> ,
   <job> $j </job>
</emp>

 
<emp empid="{$id}">
  <name><xsl:copy-of select="$n"/></name>
  <job><xsl:copy-of select="$j"/></job>
</emp>

Query 8 shows that the names of result elements may also be dynamically constructed. The equivalent XSLT instruction used to accomplish this is xsl:element.

 
<$tagname>
   <description> $d </description> ,
   <price> $p </price>
</$tagname>

 
<xsl:element name="{$tagname}">
  <description><xsl:copy-of select="$d"/></description>
  <price><xsl:copy-of select="$p"/></price>
</xsl:element>

Query 9 introduces XQuery's FLWR (pronounced "flower") expression. The FOR statement creates a collection of variable bindings, one for each node in the "ordered forest" returned by the path expression. For each of these bindings, the subsequent statements are executed. The WHERE clause filters the nodes in the collection. RETURN constructs the result.

The XSLT equivalent is similar; there's even a rough one-to-one mapping between the XQuery constructs and the XSLT instructions used. xsl:for-each corresponds to FOR, xsl:if corresponds to WHERE, and xsl:copy-of corresponds to RETURN. Note that in both the XQuery and XSLT versions, this particular query could be formed differently. Instead of using WHERE or xsl:if, an XPath predicate could be used.

This correspondence is rough, because slightly different processing models are used. XSLT does not need to use variables here, because its notion of context includes a current node and current node list. XQuery needs the use of variables here because it retains no such context. Also, the "ordered forest" returned by the path expression in the FOR statement is what dictates the order of the result. In XSLT, the XPath expression returns a node-set rather than a list. xsl:for-each then operates on that node-set using document order. This distinction may seem somewhat academic, but it greatly simplifies the concept of node-sets, which conveniently inherits the semantics of sets. For a given node-set, the user doesn't need to worry about order until certain kinds of operations are performed. Order is not part of the set; it is applied to the set. In any case, XQuery's "ordered forest" is not consistent with the semantics of XPath.

Since all of the remaining XQuery examples stand alone as queries, the equivalent query in XSLT will be expressed as a full stand-alone stylesheet. The use of xsl:transform as opposed to xsl:stylesheet is deliberate.

 
FOR $b IN document("bib.xml")//book
WHERE $b/publisher = "Morgan Kaufmann"
AND $b/year = "1998"
RETURN $b/title

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:for-each select="document('bib.xml')//book">
      <xsl:if test="publisher='Morgan Kaufmann' and year='1998'">
        <xsl:copy-of select="title"/>

      </xsl:if>
    </xsl:for-each>
  </xsl:template>
</xsl:transform>

Query 10 introduces the "L" in "FLWR". LET binds a variable to a value, which may be a scalar or a collection. In this case, it is bound to a number. The use of a LET statement below a FOR clause is akin, in XSLT, to declaring a variable inside the body of xsl:for-each. The equivalent XSLT query shown below does precisely this (using two variables only for convenience).

XQuery's distinct() function filters out all duplicates, where “two elements are considered to be duplicates if their values (including name, attributes, and normalized content) are equal.”[3] Precisely what this means is unclear. Also, the distinct() function is said to return an "unordered set of elements." Assuming that the path expression in the FOR statement is what determines the order of the result, the resulting order when using the distinct() function is apparently undefined. This too is unclear. XQuery is a work in progress; accordingly, it should not be criticized too heavily for underspecification. However, I believe there is a greater ground for criticism to the extent that XQuery deviates from established W3C standards, regarding, for example, what is returned by an XPath expression.

In XPath, the equals (=) operator compares the string-value of nodes. Assuming this approximates an XQuery comparison between duplicates, the XSLT query shown below filters duplicates by selecting the first node in document order for each unique value found. The problem of finding unique values is essentially what's known as the grouping problem. XSLT lacks an intuitive way of filtering duplicates. Thus, while it is possible to accomplish this in XSLT, it is not very convenient. This problem is a well-known and common one, and a solution to it is among the requirements listed in the XSLT 2.0 requirements working draft[6].

The lack of an avg() function in XSLT is another convenience issue. It is certainly possible to compute the average of a set of values, by using sum() and count(). While this is slightly less convenient than if an avg() function were available, it is certainly more intuitive than the XSLT solution to the grouping problem. In any case, the requirement for an extended set of aggregation functions is included in the XPath 2.0 requirements working draft[7].

FOR $p IN distinct(document("bib.xml")//publisher)
LET $a := avg(document("bib.xml")
   /book[publisher = $p]/price)
RETURN 
   <publisher>
      <name> $p/text() </name> ,
      <avgprice> $a </avgprice>

   </publisher>

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:for-each select="document('bib.xml')//publisher[not(.=preceding::publisher)]">
      <xsl:variable name="prices" 
                    select="document('bib.xml')/book[publisher=current()]/price"/>
      <xsl:variable name="avgPrice" select="sum($prices) div count($prices)"/>
      <publisher>

        <name><xsl:value-of select="."/></name>
        <avgprice><xsl:value-of select="$avgPrice"/></avgprice>
      </publisher>
    </xsl:for-each>
  </xsl:template>

</xsl:transform>

Queries 11 and 12 introduce the ability to nest a FLWR expression within an element constructor, in order to return a well-formed XML document.

Again, in these examples, there is a close one-to-one correspondence between XSLT instructions and XQuery clauses. In fact, the XSLT queries almost look like possible formulations of XQuery into XML syntax. When the difference in appearance between two languages is this small, one has to wonder whether they should be promoted as separate languages (one for query and one for transformation), or whether they should build from a common base, both semantically and syntactically.

Note that the optional simplified syntax for XSLT is used here, specified in 2.3 Literal Result Element as Stylesheet in the XSLT recommendation[2]. In all of the queries where it is possible to do so, I will use this syntax in order to 1)illustrate the possible conciseness of XSLT, and 2)make explicit the fact that template rules are not being used.

Many of the example queries cannot fit within this syntax, not because they use template rules, but because the specified result is an XML fragment, rather than a well-formed document containing only one root element. The simplified syntax can only specify a result tree having one root element.

<big_publishers>
   FOR $p IN distinct(document("bib.xml")//publisher)
   LET $b := document("bib.xml")/book[publisher = $p]
   WHERE count($b) > 100
   RETURN $p
</big_publishers>

<big_publishers xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:for-each select="document('bib.xml')//publisher[not(.=preceding::publisher)]">
    <xsl:variable name="b" select="document('bib.xml')/book[publisher=current()]"/>

    <xsl:if test="count($b) > 100">
      <xsl:copy-of select="."/>
    </xsl:if>
  </xsl:for-each>
</big_publishers>

<author_list>
   FOR $a IN distinct(document("bib.xml")//author)
   RETURN
      <author>
         <name> $a/text() </name>,
         FOR $b IN document("bib.xml")//book[author = $a]
         RETURN $b/title
      </author>
</author_list>

<author_list xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:for-each select="document('bib.xml')//author[not(.=preceding::author)]">
    <author>
      <name><xsl:value-of select="."/></name>
      <xsl:for-each select="document('bib.xml')//book[author=current()]">
        <xsl:copy-of select="title"/>

      </xsl:for-each>
    </author>
  </xsl:for-each>
</author_list>

Queries 13 and 14 show convenient uses of XQuery's variable binding mechanism. Once again, the XSLT equivalents primarily differ in mere syntax.

<result>
   LET $a := avg(//book/price)
   FOR $b IN /book
   WHERE $b/price > $a
   RETURN
      <expensive_book>
         $b/title ,
         <price_difference>
            $b/price - $a
         </price_difference>
      </expensive_book>

</result>

<result xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:variable name="avgPrice" select="sum(//book/price) div count(//book/price)"/>
  <xsl:for-each select="/bib/book[price > $avgPrice]">
    <expensive_book>

      <xsl:copy-of select="title"/>
      <price_difference>
        <xsl:value-of select="price - $avgPrice"/>
      </price_difference>
    </expensive_book>
  </xsl:for-each>

</result>

LET $tagname := name($e)
RETURN
   <$tagname>
      $e/@*,   -- replicates the attributes of $e
      2 * number($e)
   </$tagname>

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:variable name="e" select="/foo"/>

  <xsl:variable name="tagname" select="name($e)"/>
  <xsl:template match="/">
    <xsl:element name="{$tagname}">
      <xsl:copy-of select="$e/@*"/>
      <xsl:value-of select="2 * $e"/>
    </xsl:element>

  </xsl:template>
</xsl:transform>

Query 15 introduces the SORTBY clause. Note that sorting is handled differently in XQuery than in XSLT. The SORTBY clause is applied after an intermediate result has been constructed. To do this in XSLT would require processing a constructed tree as a node-set, using either a node-set() extension function or XSLT 1.1[8]. Sorting in XSLT is applied to a selected node-set before a result is constructed for each of the nodes in that node-set. As it turns out, the example below sorts on values that are available before the intermediate result is constructed. Thus, though the corresponding XSLT query does not mean exactly the same thing, it will achieve the same result.

<publisher_list>
   FOR $p IN distinct(document("bib.xml")//publisher)
   RETURN
      <publisher>
         <name> $p/text() </name> ,
         FOR $b IN document("bib.xml")//book[publisher = $p]
         RETURN
            <book>
               $b/title ,
               $b/price
            </book> SORTBY(price DESCENDING)
      </publisher> SORTBY(name)

</publisher_list>

<publisher_list xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:for-each select="document('bib.xml')//publisher[not(.=preceding::publisher)]">
    <xsl:sort select="."/>
    <publisher>
      <name><xsl:value-of select="."/></name>

      <xsl:for-each select="document('bib.xml')//book[publisher=current()]">
        <xsl:sort select="price" order="descending"/>
        <book>
          <xsl:copy-of select="title"/>
          <xsl:copy-of select="price"/>
        </book>

      </xsl:for-each>
    </publisher>
  </xsl:for-each>
</publisher_list>

Query 16 introduces the BEFORE and AFTER extensions to the XPath syntax. “BEFORE operates on two lists of elements and returns those elements in the first list that occur before at least one element of the second list in document order.”[3] The XPath axes for document order, irrespective of hierarchy, are preceding and following. Thus, it is possible to express this in XPath, although it is not very intuitive. The XSLT solution below uses three variables in an attempt to make it more readable.

The XSLT approach used below gets the intersection of two node-sets, namely all elements after the first incision, and all elements before the second incision. The technique used for getting the intersection of two node-sets, as shown in the binding of the $between variable, is not very intuitive. Among the requirements in the XPath 2.0 requirements working draft[7] is support for intersection and difference functions. More to the point, a future version of XPath may provide equivalents to XQuery's BEFORE and AFTER operators, although these are not currently listed in the requirements. Again, this is a matter of convenience. In addition to the matter of convenience, such operators might serve as optimization hints to an XSLT processor. This would be particularly important in the context of using XSLT as a query language.

<critical_sequence>
   LET $p := //procedure[1]


   FOR $e IN //* AFTER ($p//incision)[1] 
          BEFORE ($p//incision)[2]
   RETURN shallow($e)
</critical_sequence>

<critical_sequence xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:variable name="p" select="(//procedure)[1]"/>
  <xsl:variable name="before" select="$p//incision[2]/preceding::*"/>
  <xsl:variable name="after" select="$p//incision[1]/following::*"/>

  <xsl:variable name="between" select="$before[count(.|$after)=count($after)]"/>
  <xsl:for-each select="$between">
    <xsl:copy/>
  </xsl:for-each>
</critical_sequence>

<critical_sequence xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:variable name="p" select="(//procedure)[1]"/>
  <xsl:for-each select="$p//incision[1]/following::*[not(ancestor-or-self::incision)
                                                     and count(preceding::incision) = 1]">
    <xsl:copy/>
  </xsl:for-each>
</critical_sequence>

Query 17 introduces the empty() function, which operates exactly the same on a node-set as XPath's not() function. The XSLT equivalent to this query uses the same approach as in the last query, which is to find the intersection of two node-sets.

-- Finds potential lawsuits
FOR $p in //procedure
WHERE empty($p//anesthesia BEFORE ($p//incision)[1])
RETURN $p

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:for-each select="//procedure">
      <xsl:variable name="before" select="(.//incision)[1]/preceding::*"/>
      <xsl:if test="not(.//anesthesia[count(.|$before)=count($before)])">

        <xsl:copy-of select="."/>
      </xsl:if>
    </xsl:for-each>
  </xsl:template>
</xsl:transform>

Query 18 shows how conditional expressions in XQuery compare with those in XSLT. Once again, they differ primarily in syntax.

FOR $h IN //holding
RETURN
   <holding>
      $h/title,
      IF $h/@type = "Journal"
      THEN $h/editor
      ELSE $h/author
   </holding> SORTBY (title)

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:for-each select="//holding">

      <xsl:sort select="title"/>
      <holding>
        <xsl:copy-of select="title"/>
        <xsl:choose>
          <xsl:when test="@type='Journal'">
            <xsl:copy-of select="editor"/>

          </xsl:when>
          <xsl:otherwise>
            <xsl:copy-of select="author"/>
          </xsl:otherwise>
        </xsl:choose>
      </holding>

    </xsl:for-each>
  </xsl:template>
</xsl:transform>

Query 19 introduces XQuery's SOME operator, the "existential quantifier". Testing whether a condition applies for some node within a given node-set is natural in XPath. In the XSLT solution below, if any descendant para element contains both "sailing" and "windsurfing", then the returned node-set will be non-empty and the test will return true.

FOR $b IN //book
WHERE SOME $p IN $b//para SATISFIES
   contains($p, "sailing") 
   AND contains($p, "windsurfing")
RETURN $b/title

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:for-each select="//book">
      <xsl:if test=".//para[contains(., 'sailing') and contains(., 'windsurfing')]">
        <xsl:copy-of select="title"/>

      </xsl:if>
    </xsl:for-each>
  </xsl:template>
</xsl:transform>

Query 20 introduces XQuery's EVERY operator, the "universal quantifier". Testing whether a condition applies for every node within a node-set is not quite as natural in XSLT, though it is possible. Two possible XSLT solutions are presented below (the second as a comment).

The first solution determines whether the number of para elements equals the number of para elements that contain "sailing". If so, then we know there are no para elements that do not contain "sailing". Since this also might mean that there are simply no para elements, we ensure that that is not the case by additionally testing that there is at least one of them.

The second solution tests whether any of the nodes in the node-set do not satisfy the given constraint. If any do not, then the test will return false. Since we want to determine whether or not every descendant para element contains "sailing", we test the emptiness (via not()) of the node-set consisting of para elements that do not contain "sailing". If it is empty, then we at least know there are no para elements that do not contain "sailing". Since this also might mean that there are simply no para elements, we ensure that that is not the case by additionally testing that there is at least one of them.

The current working draft of the XPath 2.0 requirements states that XPath 2.0 “Must Support Explicit "For Any" or "For All" Comparison and Equality Semantics”[7]. Thus, we can expect that XPath will support something similar to XQuery's existential and universal quantifiers.

FOR $b IN //book
WHERE EVERY $p IN $b//para SATISFIES
   contains($p, "sailing")
RETURN $b/title

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:for-each select="//book">

      <xsl:if test="count(.//para)=count(.//para[contains(., 'sailing')]) and .//para">
          <!-- OR: "not(.//para[not(contains(., 'sailing')]) and .//para" -->

        <xsl:copy-of select="title"/>
      </xsl:if>
    </xsl:for-each>
  </xsl:template>
</xsl:transform>

Query 21 introduces XQuery's filter function, which provides functionality very similar to a subset of XSLT's pattern-matching template rules. “This function takes two operands, each of which is an expression that, in general, evaluates to an ordered forest of nodes. filter returns copies of some of the nodes in the forest represented by the first operand, while preserving their hierarchic and sequential relationships.”[3] Essentially, it filters out all descendant nodes of those in the first set that aren't in the second, resulting in a tree that consists of a shallow copy of each remaining node preserved in its original hierarchy with respect to the other remaining nodes. This is exactly the sort of thing that can be done using XSLT template rules, as shown in the below XSLT solution. Note that the built-in rules for elements and text nodes are overridden in this example.

Incidentally, this problem can also be solved in XSLT without using template rules. The second XSLT solution below is arguably closer to the semantics of XQuery's filter function, although it is much more painful to look at. It uses explicit recursive processing in conjunction with a named template. This is included in order to emphasize the handiness of the implicit recursive processing of XSLT's template rules.

LET $b := document("cookbook.xml")
RETURN
   <toc>
      filter($b, $b//section | $b//section/title | $b//section/title/text() )
   </toc>

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <toc>

      <xsl:apply-templates select="document('cookbook.xml')/node()"/>
    </toc>
  </xsl:template>
  <xsl:template match="section | section/title | section/title/text()">
    <xsl:copy>
      <xsl:apply-templates/>

    </xsl:copy>
  </xsl:template>
  <xsl:template match="* | text()"/>
</xsl:transform>

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">

    <toc>
      <xsl:call-template name="filter">
        <xsl:with-param name="first" select="document('cookbook.xml')"/>
        <xsl:with-param name="second"
                        select="//section | //section/title | //section/title/text()"/>
      </xsl:call-template>
    </toc>

  </xsl:template>
  <xsl:template name="filter">
    <xsl:param name="first"/>
    <xsl:param name="second"/>
    <xsl:for-each select="$first/node()">
      <xsl:choose>

        <xsl:when test="count(.|$second)=count($second)">
          <xsl:copy>
            <xsl:call-template name="FILTER">
              <xsl:with-param name="first" select="."/>
              <xsl:with-param name="second" select="$second"/>
            </xsl:call-template>

          </xsl:copy>
        </xsl:when>
        <xsl:otherwise>
          <xsl:call-template name="FILTER">
            <xsl:with-param name="first" select="."/>
            <xsl:with-param name="second" select="$second"/>

          </xsl:call-template>
        </xsl:otherwise>
      </xsl:choose>
    </xsl:for-each>
  </xsl:template>
</xsl:transform>

Query 22 introduces XQuery's facility for user-defined functions. The XSLT equivalent uses a recursive named template to achieve the same result as XQuery's recursive function. Note, however, that a recursive named template, which may function similarly to a XQuery user-defined function, is qualitatively different, because a named template always produces a tree, rather than an arbitrary node-set or arbitrary value of any data type. By processing intermediate trees as node-sets (using a node-set() extension function or XSLT 1.1[8]), this limitation can arguably be gotten around, but the fact remains that user-definable functions, apart from extension functions, are not currently supported in XSLT.

NAMESPACE xsd = "http://www.w3.org/2000/10/XMLSchema-datatypes"

FUNCTION depth(ELEMENT $e) RETURNS xsd:integer
{
   -- An empty element has depth 1
   -- Otherwise, add 1 to max depth of children
   IF empty($e/*) THEN 1
   ELSE max(depth($e/*)) + 1
}

depth(document("partlist.xml"))

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:template name="depth">
    <xsl:param name="node"/>
    <xsl:param name="level" select="1"/>
    <xsl:choose>
      <xsl:when test="not($node/*)">
        <xsl:value-of select="$level"/>

      </xsl:when>
      <xsl:otherwise>
        <xsl:call-template name="depth">
          <xsl:with-param name="level" select="$level + 1"/>
          <xsl:with-param name="node" select="$node/*"/>
        </xsl:call-template>

      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>
  <xsl:template match="/">
    <xsl:call-template name="depth">
      <xsl:with-param name="node" select="document('partlist.xml')"/>

    </xsl:call-template>


  </xsl:template>
</xsl:transform>

In the XSLT equivalent to Query 23, we are able to effect the same result as the XQuery query by leveraging the built-in recursive processing of XSLT's template rules, rather than by implementing a recursive named template. It is a matter of debate which of the two approaches below is a better route to achieving the desired result. In my opinion, the implicit, "automatic" recursive processing supplied by template rules is easier to follow than the explicit recursion used in the XQuery version.

FUNCTION connected(ELEMENT $e) RETURNS LIST(ELEMENT)
{ 
    $e/* UNION $e/@*->* 
}

FUNCTION reachable(ELEMENT $e) RETURNS LIST(ELEMENT)
{ 
    $e UNION reachable(connected($e)) 
}

reachable(document("company.xml")/emp[serial="12345"])

<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:variable name="e" select="//emp[serial='12345']"/>
    <xsl:apply-templates select="$e/* | id($e/@*)"/>
  </xsl:template>
  <xsl:template match="*">

    <xsl:copy>
      <xsl:apply-templates select="* | id(@*)"/>
    </xsl:copy>
  </xsl:template>
  <xsl:template match="text()"/>
</xsl:transform>