This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Built in templates
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] Built in templates
- From: tcn at melvaig dot co dot uk (Trevor Nash)
- Date: Thu, 05 Apr 2001 10:47:51 GMT
- Organization: Melvaig Software Engineering Limited
- References: <191E23677373D411BFB900D0B7A7BA28025C47@mail.vbninternal.com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
On Thu, 5 Apr 2001 10:30:18 +0100, you wrote:
>Well I can't remember the exact name but there are builtin
>rules that for example copy all the text() elements accross
>into the output from unrecognised nodes.
Close: I believe the correct term is built-in template rule.
Your example is an instance of something I also find untidy: the need
to trigger a given template in any of a number of modes. Yes, I know
the trick of using call-template, but that is also untidy for small
templates especially with parameters.
Which brings me on to the other oddity: that while the built-in
templates pass on the mode, they do not pass on parameters. I can see
the rationale in the context of an environment using templates from
different authors which makes use of defaults for parameters: but that
problem seems to be small compared to the bad interaction with default
templates.
The language could be changed in a compatible way, e.g
- a new attribute 'modes' on xsl:template which takes a list of
modes. Meaning: exactly equivalent to replicating the template for
each mode. (You can allow mode='' to be given to include the default
mode).
- a new attribute 'use-current-mode' on apply-templates and
call-templates. Meaning: if 'yes' then same as mode="whatever" in the
replicated copies above. Default 'no'.
- a new attribute 'pass-parameters' on apply-templates and
call-templates. Meaning: if 'yes' then same as providing the
necessary with-param elements to pass the values of all parameters
declared on the enclosing template which had values. The effect is
recursive for any built-in templates invoked by apply-templates.
Default 'no'
Anybody else thinking along these lines? I have to confess I did not
check the XSLT 1.1 stuff before I wrote this, so I'm prepared for the
answer 'we already thought of that'. Indeed I would be surprised if
this is not the case.
Regards,
Trevor Nash
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list