XSLT Draft: Modes vs. Variables

["Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>]

I've just been through the new XSLT draft. The WG has come up with some
nifty features (some of which might be related to the feedback from this
mailing list ;-), with the result that I like this draft much better then
the previous one (which was much better then the one before it). The
standards are also reorganizing in the right direction - we now have XSLT as
opposed to XSL, and the unification of the patterns with XPointer has begun.
If things continue to improve at this pace, the final draft would be all we
can hope for. Keep on the good work!

Unifying macros and templates is neat. I would like to know, however, what
the expected behavior is when a named template has a match pattern. Is the
call to the template ignored unless the current node matches the pattern? Is
the named template considered together with normal templates when matching
for document elements? I infer from the fact this was left unspecified that
the issue was not resolved yet.

The new <xsl:variable> and <xsl:param-variable> are a life-saver. I was
putting off writing some particularly tricky XSL transformations which
really needed them; now I can forge ahead without resorting to messy
workarounds. They do raise a question, though: does it make sense to replace
template modes with a test attribute?

I'm aware this is re-opening a discussion from half a year ago, but the
situation has changed due to XSLT's variables. Think of it in the following
manner: suppose that in the previous draft, variables were introduced in the
new XSLT form, and there was no 'mode' attribute for <xsl:template>. People
would have been forced to write:

<xsl:template match="...">
    <xsl:choose>
        <xsl:when test="{$mode}='...'">
            ...
        </xsl:when>
        ...
    </xsl:choose>
</xsl:template>

Which gets the job done but is pretty inconvenient. It is also limited in
that all the possibilities need to be written in one place. In this
hypothetical alternate history, would the best solution have been to add a
'mode' attribute or a 'test' attribute to <xsl:template>?

My own opinion is that 'test' would have been the right way to go - it is
simpler to define its semantics (treat the template as if it had an <xsl:if>
around all the code, except for parameter definitions), it is more powerful
(tests can be for more then a simple equality) and it is one less concept in
a complex system (always a good thing if you can get away with it).

Looking back at my XSL sheets there were several occasions where I wanted to
write:

<xsl:template mode="mode1|mode2" ...>

And had to factor our the common code to a macro. Using tests would have
allowed me to write:

<xsl:template test="{$mode}='mode1' or {$mode}='mode2'" ..>

Instead. In the tricky code I have mentioned above, there are some cases
where the possible handling of each element depend on more then one
variable, in which case using 'test' would allow me to naturally factor a
large and complex template.

How about it?

    Oren Ben-Kiki



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