Re: [xsl] variable question

Subject: Re: [xsl] variable question
From: Bruce D'Arcus <bdarcus@xxxxxxxxxxxxx>
Date: Sun, 29 Aug 2004 19:35:00 -0400
On Aug 29, 2004, at 4:32 PM, Jeni Tennison wrote:

For XSLT 2.0, I think I'd turn the reftype template into a function
instead, since it just returns a string. I'd keep the title-before
template as a template since it might return some XML when you revise
it in the future. So it would look more like:

<xsl:template match="mods:titleInfo[not(@type='abbreviated')]"
  <span class="{if (../mods:relatedItem[@type = 'host'])
                then 'title'
                else 'title italic'}">
    <xsl:apply-templates select="." mode="title-before"/>
   	<xsl:apply-templates select="mods:title"/>
   	<xsl:apply-templates select="mods:subTitle"/>
   	<xsl:apply-templates select="." mode="title-after"/>

<xsl:template match="mods:titleInfo" mode="title-before">
  <xsl:if test="mods:reftype(parent::mods:relatedItem) = 'chapter'">

<xsl:function name="mods:reftype" as="xs:string">
  <xsl:param name="relatedItem" as="element(mods:relatedItem)" />
    <xsl:when test="$relatedItem/@type = 'host'">
      <xsl:variable name="issuance" as="xs:string"
        select="$relatedItem/mods:originInfo/mods:issuance" />
        <xsl:when test="$issuance = 'continuing'">article</xsl:when>
        <xsl:when test="$issuance = 'monographic'">chapter</xsl:when>

Interesting. Thanks for this Jeni; very informative as always!

One of things I'm doing in this system that is new (and IMHO innovative) is trying to eliminate the typical typing system you see in existing bibliographic systems like bibtex.

My argument is that the recursive structure of the data is a nice match to the processing logic of XSLT, and that to force, for example, separate templates for every single minor variation of type (books, report, journal article, magazine article, blah, blah, blah) is both inefficient and error prone (though no doubt easier to code!).

So ... where the stylesheets currently are is there are three "types" which are in essence proxies for structural features. They are the fallbacks. That's what you see, and ultimately what the user will deal with (easier to think in terms of "book" rather than "record without relatedItem and with monographic issuance"!).

However, when I ultimately figure out how to add customizability, it will need to be possible for the user to specify additional "types" where the default's are for some reason insufficient. So, in your function, the "otherwise" choice will probably be to look at the value of the <mods:genre> element. So, style file has an element, say, <reftype name="memo">, and XSLT knows that for those records that have a genre value of the same name, it will use the formatting specified there to process the record.

I'm curious if you think that changes how I ought to approach constructing the function and related templates? Or maybe I'm not thinking about this right to begin with?


Current Thread