This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: XSLT's Template Dispatch
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] XSLT's Template Dispatch
- From: "Clark C. Evans" <cce at clarkevans dot com>
- Date: Fri, 5 Jan 2001 13:36:41 -0500 (EST)
- Reply-To: xsl-list at lists dot mulberrytech dot com
On Fri, 5 Jan 2001, David Carlisle wrote:
> The first case, <when
> test="//author[generate-id(.)=$id]">, has a path
> expression returning the node-set consisting of any
> author element having an identifier equal to the current
> node's identifier. Therefore, if the current node
> happens to be an author, the node-set returned will be
> non-empty, which converts to a true boolean value.
>
> isnt this just self::author ?
Yes. For the *particular* case you mentioned, you could
change the test to "self::author"; this is actually a
pretty snazzy optimization. However, I was trying
to demonstrate a automated general-case:
To translate any <template match="..." construct having
an XPath expression X, first add a new <when test="..."
clause to the dispatch template. The path expression for
the when clause is formed formed by appending "[generate-id(.)=$id]"
to X, and if X is relative prepending "//". Then move the
body of the template into the body of the when clause, replacing
each call to apply-templates with a call to the apply template.
Very sorry that the description was not clear. The point
of the article is to show how one could re-write template
usage into a more procedural style. Not that you would
ever want do to this for production purposes; however, it
is instructive to see the equivalence between the two forms.
;) Clark
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list