Re: [xsl] dynamically applying templates

Subject: Re: [xsl] dynamically applying templates
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Tue, 14 Sep 2004 14:13:57 -0400
Hi Bruce,

At 01:51 PM 9/14/2004, you wrote:
So perhaps your calling template would select the appropriate
cs:reftype element in the config file to process:

<xsl:apply-templates name="style-biblio"
select="$styles/cs:citationstyle/cs:content/cs:bibliography[@author- as-sort-order='yes']/cs:entry/cs:reftype[@name='book']">
<xsl:with-param name="source" select="."/>

The "calling template" in this case being the mods namespaced stuff?


Note that while the values 'yes' and 'book' are hardcoded here, they certainly wouldn't have to be. Hence the selection of a node from the configuration file to process would be "dynamic".


<xsl:template match="mods:mods">
select="$styles/cs:citationstyle/cs:content/cs:bibliography[@author-as- sort-order='yes']/cs:entry/cs:reftype">
<xsl:with-param name="source" select="."/>

Note also that the name attribute on the apply-templates element is

Yes: sorry. I modified a variable declaration you had earlier posted, and neglected to remove the name.

OK, so with respect both of your comments below (as well as the above),
I'm still a bit fuzzy on how to use parameters -- how you're using them
in this context --  and about tunneling ...

And then

<xsl:template match="cs:reftype">
  <xsl:param name="source"/>
    <xsl:with-param name="source" select="."/>

In this case, what exactly is the parameter doing? Are you using this precisely to do the, as you later say, "jumping back and forth between the trees"? So here you're apply-templates to the cs:* elements, and elsewhere to mods:*?

Yes. I'm matching a node in your configuration (the reftype), since its organization and content will drive processing. But I'm passing a reference back to the mods source so that it can be "jumped back to" anytime I need its data.

This way, not only the content, but also the structure of your cs:reftype can drive processing, without fancy tests.

   <!-- the parameter passing shouldn't be necessary w/ XSLT 2.0
         'tunneling parameters' -->

So are you saying here I should be defining a "source" param at the top of my stylesheet using tunneling='yes", without a select statement?

No, this parameter is purely local, not global; it's declared only in the template where a *particular* mods source node is matched, not globally.

As for the tunneling, use it if you can; I've only implemented this kind of thing in XSLT 1.0, where you have to pass the parameter explicitly through every template.


<xsl:template match="cs:title">
  <xsl:param name="source"/>
  <!-- do your title thing here, grabbing data from
       $source (the mods source) as necessary -->

Here's I'm confused on the $source reference. Does this suggest I am using the source param and doing something like so?

<xsl:template match="cs:title">
  <xsl:param name="source"/>
  <!-- do your title thing here, grabbing data from
       $source (the mods source) as necessary -->
  <xsl:apply-templates select="mods:titleInfo">
    <xsl:with-param name="source" select="mods:mods"/>

Presumably that would have to be

<xsl:apply-templates select="$source/mods:titleInfo"/>

(And since here you're jumping back to the node in the source tree, you don't need to pass a parameter back -- certainly not one that binds a non-existent mods:mods child of the cs:title context node.)

Sorry, but I feel like a blind man here, and I need to understand it
better before I get farther.

It's a pretty sophisticated application of the XSLT processing model on two documents in tandem, so it's not easy to understand.

You have to start by assimilating the processing model itself, including the notions of context nodes, relative paths (including the default child:: axis), and template traversal. If your brain can't track what's happening as the processor traverses a single document, it's probably going to freeze up completely when you try to conceive of traversing two documents back-and-forth. But you have chosen to address a very ambitious requirement.

The only other way of driving the structure of your output from the structure of your configuration (as opposed to the structure of your primary source) is to use conditional logic, which would likely prove to be insanely complex. The XSLT processing model is designed to allow you easily to reflect the structure of the input transparently in the output. But you want explicitly to *rearrange* the input data based on what your configuration says. Rearranging data isn't difficult if you can use 'pull' logic, but you can't since the new arrangement isn't known in advance. So I'm suggesting, in effect, that you 'push' it from your configuration file.

The output I'm currently getting is just:

<html xmlns="";><span
class="creator"></span><span class="creator"></span><span
class="creator"></span><span class="creator"></span></html>

.... which is a big mess!  Probably means beyond the basic problem of
how to select the right template, I also need to use modes (there's
only one "creator" in this file).

Without seeing complete source and stylesheet, it would be rather absurd of me to try and diagnose this.


====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================

--+------------------------------------------------------------------ XSL-List info and archive: To unsubscribe, go to: or e-mail: <mailto:xsl-list-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx> --+--

Current Thread