Re: [xsl] Second of two consecutive call-template instructions appears to affect the first?

Subject: Re: [xsl] Second of two consecutive call-template instructions appears to affect the first?
From: Sebastian Tennant <sebyte@xxxxxxxxxxxxxxx>
Date: Wed, 15 Mar 2006 21:59:21 +0000
Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> wrote:

> [...]
>
> Like an XML document, a stylesheet in XSLT is not a "script" but
> rather a tree-shaped thing. Those branches called "templates" present
> (tree-shaped) chunks of results that will be "grafted" to the
> output. But internally, the templates have no order: they're just laid
> out onto the table, as it were, and applied based only on when they
> match (or are called by name). When that happens, each one is
> considered to be a self-contained, and special accommodation has to be
> made for it to "know" anything outside the context of its
> application. In XSLT 1.0, local variables and parameters fall outside
> this line. (This has been modified in 2.0 with "tunnel parameters",
> which are somewhat more flexible, although they too have to be
> declared in templates where they are actually used, unless I'm
> mistaken.)

Many thanks Wendell for your comprehensive explanation.  Events
somehow conspired to convince me that call-template behaved
differently to apply-templates, and that I didn't need to explicitly
pass parameters from the caller, nor declare them in the callee.

As I wrote the stylesheet (based on this assumption), each new
addition of conditional logic seemed to work, nay, _did_ work, as I
intended, further convincing me of my incorrect understanding!

Anyhow, the stylesheet is now about 20 lines longer due to the
addition of lines like this in the callers:

  (1) <xsl:with-param name="name"><xsl:value-of select="$name" /></xsl:with-param>

And lines like this in the callees:

  (2) <xsl:param name="name" />

But at least it works!

It was probably also the seemingly pointless and repetitive nature of
this mechanism that served to further convince me that "this can't be
necessary!"  I can see why 'tunnel parameters' have been introduced,
if they serve to cut down on the number of lines like these,
especially (1). 

Once again many thanks.

sdt

Current Thread