Re: [xsl] dynamically applying templates

Subject: Re: [xsl] dynamically applying templates
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Wed, 15 Sep 2004 15:00:23 -0400
Hi Bruce,

At 02:46 PM 9/15/2004, you wrote:
.... and add a template to match mods:mods (but notice I pulled the mode, imagining that the "bibliography" mode is to handle nodes in the config document.

...
Within those templates, there were two core modes: full and short.
Originally, I had carried the citation/bibliography thing through the descendants, but that doesn't really make much sense when you consider footnote citations are often full bib references. Hence, full and short (for titles, names, etc.).


I tend to think this logic makes sense to keep.

I don't mean to second-guess your reasoning. I just wanted to be clear that the "bibliography" mode didn't appear to be helping in this particular case. If you need it for some larger reason, fine. (Just make sure it doesn't clash with the traversal of the cs: nodes. Maybe they're the ones that don't need the mode.)


That's the template where we'll jump trees, so --

<xsl:template match="mods:mods">
<xsl:apply-templates select="$style-biblio/cs:entry/cs:reftype[@name='book']"
mode="bibliography">
<!-- of course the value 'book' should probably be parameterized -->

How and why? ;-)

Well, by using a variable or parameter to tweak which reftype is selected. Presumably there will be others, and which one is picked should depend on ... whatever it depends on. In fact, this is the whole "dynamic selection" of your template -- the particular node that's selected should depend on which configuration you want to follow in this instance.


Note: I do have a function (again, with Jeni's help) that determines the type of mods record (book, etc.), but I've not thought about whether and how to bring that over to the cs:* stuff.

That might be exactly what you want.


Say if your input made the reference type explicit, <mods type="book">...</mods>, then the select expression could read select="$style-biblio/cs:entry/cs:reftype[@name=current()/@type]

... thereby choosing whatever reftype matched the type given in the mods input.

Your function might be to do exactly this, for all I know. :->

There the type is just a straight attribute value.

Yes: in the configuration data the values have to be hardcoded, because presumably they each map to a different reference type -- whatever range of reftypes might be present in the source.


   <xsl:with-param name="source" select="."/>
    <!-- this is where we jump to the other tree, carrying the original
       context with us as the $source -->

Original context is mods:mods? I am jumping to the other tree with the select statement on the apply-templates, and then jumping back to mods:mods using the with-param select?

Well of course in XSLT the context changes with each template match, so yes (except that it's no more "original" than the context you shift to when you match the selected node).


The with-param select does not jump you back; what jumps you back is another apply-templates, or more simply a value-of, which calls into $source with an XPath.

(The with-param is only necessary to "carry state" as new templates are applied, and may be completely unnecessary if those tunneling parameters work, since that's what they do.)

Also, a niggle: any particular reason why your configuration couldn't be

<bibliography author-as-sort-order="yes">
  <entry reftype="book">
    <title font-style="italic" after=", "/>
    <creator/>
  </entry>
</bibliography>

thereby making it a bit tighter and easier to handle?

I simplified the config file a lot here to keep it as clear as possible. The full structure would be schematically:


citationstyle
        info (the metadata)
        content
                names
                terms
                citation
                bibliography

So, the business I'm dealing with here relates to just the last two, and needs to happen in two respective modes: citation and bibliography.

I was just curious why you have a "reftype" layer as an element inside the bibliography config structure, since it seems to be providing no information other than the reference type, which could equally well be expressed as a name-value pair on the "entry" parent. The extra wrapper seems just to be getting in the way here.


I hope this helps clear things up.

Cheers,
Wendell


====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 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: http://www.mulberrytech.com/xsl/xsl-list To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/ or e-mail: <mailto:xsl-list-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx> --+--

Current Thread