Re: [xsl] RE: syntax sugar for call-template

Subject: Re: [xsl] RE: syntax sugar for call-template
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Sat, 17 Feb 2001 12:11:56 +0000
Hi Mike,

> I think it's better that this should be an error than that the <a/>
> element is written to some "black hole" output destination.
> Certainly, <a/> shouldn't be written to the final result tree, which
> it would be in a template called using xsl:call-template.

All agreement that <a /> shouldn't be written to the final result

I wonder if there could be a typical XSLT Rec phrase like:

  "It is an error to create nodes during the instantiation of the
  content of the xsl:template element when it is called as a function;
  implementations may either signal the error or ignore the nodes
  together with their content."

This mirrors the phrasing for creating nodes other than text nodes
within xsl:attribute - ignoring nodes isn't unheard of in XSLT 1.0.

As you say, the other approach would be to have a new xsl:function
element.  This has the advantage that its content could be explicitly
constrained to hold only xsl:param, xsl:for-each, xsl:choose, xsl:if,
xsl:variable, xsl:message, xsl:fallback, xsl:return and any extension
elements (but not literal result elements).

It would also prevent us having to write complex rules concerning when
xsl:return can be included within a template body. For example, we
need to prevent:

<xsl:template name="foo">
      <xsl:return select="'bar'" />

But I guess this could be done by saying that xsl:return can never
appear during the creation of a node, i.e. within xsl:element,
xsl:attribute, xsl:processing-instruction or xsl:comment.

The other issue is whether the shortcut of:

<xsl:template name="foo">
   <bar />

should be allowed as a substitute for:

<xsl:template name="foo">
      <bar />

So if there is no value explicitly returned then the node set created
by the instantiation of the template/function should be its return
value. Otherwise this node set is ignored. But really the latter is
hardly any more unweildy than the former. Are there implementation
issues in allowing the first?

I'm sure that we'll all discuss the various ways of having XSLT user
extensions and then come back to wanting to do it the way that Saxon
does it :)



Jeni Tennison

 XSL-List info and archive:

Current Thread