Re: XSLT Draft: Modes vs. Variables

Kay Michael <Michael.Kay@xxxxxxx> wrote:
>It did occur to me that this unification of templates and macros could be
>taken a step further, since "modes" seem to be a combination of matching by
>pattern and matching by name.

Yes! But it does needs a little polish:

>... there seems to be very little
>difference between a template declared as
>
><xsl:template match="node()" mode="bo-peep" priority="[infinity]">
>
>and one declared as
>
><xsl:template name="bo-beep">.


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.

The simplest solution would be to allow three types of templates:

- Templates with a match pattern and no name. Applied for
<xsl:apply-templates select="...">. Standard semantics.

- Templates with a name and a match pattern. Applied for
<xsl:apply-templates select="..." name="...">. Semantics like moded
templates today.

- Templates with a name and no match pattern. Applied for
<xsl:apply-templates name="...">. Semantics like <xsl:call-template>, that
is the current node list and context is preserved.

Notes:

- A call to <xsl:apply-templates> with no name and no select pattern should
be IMVVVHO equivalent to <xsl:apply-templates select="*" name="name of this
template (if any">. Failing that, it should be made illegal (just like there
can't be a template without either a name or a match pattern).

- The format of the call to <xsl:apply-templates> is identical to the format
of the <xsl:template> declarations which might be invoked by it (with
"match" standing for "select"). This makes it easy to see at a glance which
templates are invoked by which call.

- There never was an agreement of what <xsl:apply-templates> without a
select pattern should mean. The following proposes that it means the context
is preserved across the call. Seems intuitive enough - thinking of 'select'
as an "operation" which sets the context of the applied template.

- This removes from the spec the <xsl:call-template> construct and the
'mode' attribute while preserving their functionality. In fact, unlike the
'test' proposal I made before, this one follows the existing semantics
almost exactly.

Seems a neat solution all around. Anything wrong with it?

Have fun.

    Oren Ben-Kiki


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