RE: Template rules vs. XQuery (was RE:"*NEVER* use for

Regarding template rules, Ben Robb wrote:
> Also, it is the only way forward if you want to do
> any kind of recursive processing.

Well, I believe you could always use recursive named templates to achieve
the same effect. I'd be quite interested if anyone can think of an instance
where template rules could not be algorithmically converted to a single
named template. Though not central to my argument, this was one of the
things I claimed in the XQuery debate on xml-dev.

Take a simple set of template rules, for example:

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

  <xsl:template match="heading">
    <title>
      <xsl:value-of select="."/>
    </title>
  </xsl:template>

  <xsl:template match="chapter">
    <section>
      <xsl:apply-templates/>
    </section>
  </xsl:template>

</xsl:stylesheet>

I think this could be automatically converted to something like the
following:

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

  <xsl:template name="applyTemplates" match="/">
    <xsl:param name="node-set" select="/"/>
    <xsl:for-each select="$node-set">
      <xsl:choose>
        <xsl:when test="self::chapter">
          <section>
            <xsl:call-template name="applyTemplates">
              <xsl:with-param name="node-set" select="node()"/>
            </xsl:call-template>
          </section>
        </xsl:when>
        <xsl:when test="self::heading">
          <title>
            <xsl:value-of select="."/>
          </title>
        </xsl:when>
        <xsl:when test="not(..)">
          <!-- built-in rule for root node -->
          <xsl:call-template name="applyTemplates">
            <xsl:with-param name="node-set" select="node()"/>
          </xsl:call-template>
        </xsl:when>
        <xsl:when test="self::*">
          <!-- built-in rule for element nodes -->
          <xsl:call-template name="applyTemplates">
            <xsl:with-param name="node-set" select="node()"/>
          </xsl:call-template>
        </xsl:when>
        <xsl:when test="self::text()">
          <!-- built-in rule for text nodes -->
          <xsl:value-of select="."/>
        </xsl:when>
        <xsl:when test="count(.|../@*)=count(../@*)">
          <!-- built-in rule for attribute nodes -->
          <!-- btw: someone please give me a better way to
               test whether the current node is an attribute -->
          <xsl:value-of select="."/>
        </xsl:when>
        <xsl:when test="self::processing-instruction() or self::comment()"/>
      </xsl:choose>
    </xsl:for-each>
  </xsl:template>

</xsl:stylesheet>


The order of the xsl:when elements, where it matters, would be determined by
the priorities given to each rule (which, within the confines of XSLT
conformance, could vary between implementations). To introduce modes, I
think all you'd need to do is include another parameter and nest it all in
another xsl:choose block.

Is there anything that I'm missing here? Or is there anything that could not
be converted in such a way? The reason I'm asking this is that XQuery
currently appears to provide all of the constructs in the latter stylesheet
above, but not the former. If the former could always be algorithmically
converted, then someone could easily implement template rule functionality
on top of an XQuery implementation (though it wouldn't necessarily be
optimized for such). I would like to determine whether this particular claim
of mine on xml-dev has any problems with it. Ultimately, I think, for XQuery
to have any advantage over XSLT in terms of optimizability for space, it
will have to do away with the parent axis, which would also do away with the
above possibility; but, for now, the parent axis is still in there.

Evan Lenz
XYZFind Corp.


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list