«

I have several texts that are to be typeset with minor
differences. I do not want to duplicate any xsl-code,
so I'm trying to find a way to reuse code, but have
changes implemented when applicable. One approach is
of course to have a specific xsl-file for every text,
and import the more general file into it. Another
approach I have thought of, is to have just one xsl-file
and conditionalize it. In the xml-files I have something
like <text work="kerner">, <text work="kerner">, etc.,
and in the xsl-file templates like

<xsl:template match="pb">
<xsl:choose>
<xsl:when test="//@verk='kerner'">
<p class="pagina"><xsl:value-of select="@n"/></p>
</xsl:when>
<xsl:when test="//@verk='kalm'">
<p class="pagina">( <xsl:value-of select="@n"/> )</p>
</xsl:when>
</xsl:choose>
</xsl:template>

This works fine, but I'd be glad to get some input on
which method is preferrable, or if there might be other
ways to do this. What are your experiences?

wrote:
> I have several texts that are to be typeset with minor
> differences. I do not want to duplicate any xsl-code,
> so I'm trying to find a way to reuse code, but have
> changes implemented when applicable. One approach is
> of course to have a specific xsl-file for every text,
> and import the more general file into it. Another
> approach I have thought of, is to have just one xsl-file
> and conditionalize it. In the xml-files I have something
> like <text work="kerner">, <text work="kerner">, etc.,
> and in the xsl-file templates like
>
> <xsl:template match="pb">
> <xsl:choose>
> <xsl:when test="//@verk='kerner'">
> <p class="pagina"><xsl:value-of select="@n"/></p>
> </xsl:when>
> <xsl:when test="//@verk='kalm'">
> <p class="pagina">( <xsl:value-of select="@n"/> )</p>
> </xsl:when>
> </xsl:choose>
> </xsl:template>
>
> This works fine, but I'd be glad to get some input on
> which method is preferrable, or if there might be other
> ways to do this. What are your experiences?
>

the tests starting with // search the entire document looking for an
attribute of that name, so they are fairly expensive. You may be better
to move them to a global variable (although probably your xslt system's
optimiser will do that anyway). Although I suspect that you meant to
test the attribute o the current pb element ? or the document element
?if so the test wants to be test="@work='kerner'] or
test="/*/@work='kerner']

whenever there is a template that just consists of a choose it's often
more convenient (and perhaps more efficient) to write it as multiple
templates

<xsl:template match="pb[@verk='kerner']">
<p class="pagina"><xsl:value-of select="@n"/></p>
</xsl:template>

<xsl:template match="pb[@verk='kalm']">
<p class="pagina">( <xsl:value-of select="@n"/> )</p>
</xsl:template>



David

David Carlisle wrote:
> the tests starting with // search the entire document looking for an
> attribute of that name, so they are fairly expensive. You may be better
> to move them to a global variable (although probably your xslt system's
> optimiser will do that anyway). Although I suspect that you meant to
> test the attribute o the current pb element ? or the document element
> ?if so the test wants to be test="@work='kerner'] or
> test="/*/@work='kerner']
Thanks for this remark. Yes, I want to test the document element,
so the /*/@work='kerner' construction would be fine, since there are
several
templates that should be conditionalized. Should I take it that you
think this
is a good method for accomplishing my goal? Or are there any drawbacks?

Or perhaps a better way to do it?

/Patrik Nyman

wrote:

> templates that should be conditionalized. Should I take it that you
> think this
> is a good method for accomplishing my goal? Or are there any drawbacks?
>
> Or perhaps a better way to do it?
>
> /Patrik Nyman
>

it's fine, although I'd use multiple templates rather than an xs:choose.
it looks neater and can be more efficient.

<xsl:template match="*">
<xsl:choose>
<xsl:when test="self::aaa">...
<xsl:when test="self::bbb">...
....

is more or less the same as

<xsl:template match="aaa">...
<xsl:template match="bbb">...

but in the first case, your system probably has to do a linear search of
the node against each test so expected time proportional to the number
of branches.

in the second case the system probably hashes the templates against the
match name at compile time so at run time doesn't have to test every
template.

this is of course all highly dependent on the processor, the processor
could in theory rewrite either form to the same internal expresssion, or
might not hash the templates or...

unless you have hundreds of choices in the choose it probably makes no
observable time difference, I think main attraction of having more
templates and less choose blocks is that it's just more the "xsl way"

David Carlisle wrote:
> wrote:
>
> > templates that should be conditionalized. Should I take it that you
> > think this
> > is a good method for accomplishing my goal? Or are there any drawbacks?
> >
> > Or perhaps a better way to do it?
> >
> > /Patrik Nyman
> >
>
> it's fine, although I'd use multiple templates rather than an xs:choose.
> it looks neater and can be more efficient.
>
> <xsl:template match="*">
> <xsl:choose>
> <xsl:when test="self::aaa">...
> <xsl:when test="self::bbb">...
> ...
>
> is more or less the same as
>
> <xsl:template match="aaa">...
> <xsl:template match="bbb">...
>
> but in the first case, your system probably has to do a linear search of
> the node against each test so expected time proportional to the number
> of branches.
>
> in the second case the system probably hashes the templates against the
> match name at compile time so at run time doesn't have to test every
> template.
>
> this is of course all highly dependent on the processor, the processor
> could in theory rewrite either form to the same internal expresssion, or
> might not hash the templates or...
>
> unless you have hundreds of choices in the choose it probably makes no
> observable time difference, I think main attraction of having more
> templates and less choose blocks is that it's just more the "xsl way"

Thanks a lot for these clarifications.

/Patrik Nyman