Fw: XSLT Draft: Modes vs. Variables

Subject: Fw: XSLT Draft: Modes vs. Variables
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Wed, 28 Apr 1999 11:18:48 +0200
I wrote:
>> There's one crucial difference: calling:
>>
>> <xsl:apply-templates mode="bo-beep" select="..."/>
>>
>> Has no equivalent using named templates. Note that the following:
>>
>> <xsl:for-each select="...">
>>     <xsl:call-template name="bo-beep"/>
>> </xsl:for-each>
>>
>> Is _not_ the same thing, since there must be only one template name
>> 'bo-beep' in the 'for-each' case.

James Clark <jjc@xxxxxxxxxx> replied:
>Huh?  It would be an error if there was more than one template rule
>declared as:
>
><xsl:template match="node()" mode="bo-peep"
>priority="[infinity]">...</xsl:template>


Exactly; therefore, given the following input document:

<foo>
    <bar>...</bar>
    <baz>...</baz>
</foo>

One can't simply translate:

<xsl:template mode="foo" select="bar">...</xsl:template>
<xsl:template mode="foo" select="baz">...</xsl:template>
<xsl:template match="foo">
    <xsl:apply-templates mode="foo" select="*">
</xsl:template>

Into:

<xsl:template name="foo" select="bar">...</xsl:template>
<xsl:template name="foo" select="baz">...</xsl:template>
<xsl:template match="foo">
    <xsl:for-each select="*">
        <xsl:call-template name="foo"/>
    </xsl:for-each>
</xsl:template>

Because there's no way to force the <xsl:call-template> to invoke the
appropriate template according to the selected element type. Therefore _as
things stand today_, the 'mode' attribute/mechanism is necessary.

>The WG considered lots of different alternatives (including not having
><xsl:call-template> and <xsl:template name="..."> at all, having a
>select attribute on xsl:call-template, combining xsl:apply-templates and
>xsl:call-template) before settling on the current design.

The current model is definitely consistent and sufficient, it is just that
IMVHO it could be made simpler (more elegant?) without effecting the feature
set. No offense for the WG - I'm sure they have good reasons for the
decisions they made.

<SideTrack>
As I mentioned before, I'm a sucker for rationale documentation in
standards. I'm also aware that standard organizations abhor retional
documentation since they are as hard to create as the standard itself.
However IMVHO rationale documentation greatly improve the quality of
standards.

For one thing, explaining why a certain design choice was made often gives
better insights on an issue then format definitions (of course the latter is
also important). It helps to steer people away from wrong interpretations.

Another benefit is that it helps weed out flawed design choices. Take this
one for example (I'm not saying it is necessarily flawed!). If the reason
for choosing this particular combination is its effect on ease of
implementation/simplicity of explaining the resulting language/size of style
sheets/efficiency of XSL processors, it settles the issue (since there's a
good technical reason). If on the other hand all the considered combinations
are more of less technically equivalent and the choice was made according to
aesthetic reasons, that would also settle the issue (after all a choice has
to be made and there's no point arguing about taste). The interesting case
is where the reasoning is flawed - on overlooked combination, or an effect
of one of the options, which might have been a deciding factor had it been
raised.

Without a rationale, reviewing the standard becomes a game of trying to
reverse-engineer the reasons for the design choices as a required part of
suggesting improvements. A fun game, but a difficult and error prone one, so
it tends to reduce the quality and quantity of the improvement suggestions.

Of course all this depends on the type of standard process you prefer. For
better or for worse, the W3C has chosen a pretty closed type of process.
That isn't necessarily bad but it does mean that suggestions in this list
and other places always face the danger of simply repeating a discussion
long settled within the WG, wasting everyone's time.
</SideTrack>

Share & Enjoy,

    Oren Ben-Kiki


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread