[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RE: syntax sugar for call-template

Subject: Re: RE: syntax sugar for call-template
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Sat, 17 Feb 2001 12:11:56 +0000
Re:  RE: syntax sugar for call-template
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
tree.

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">
   <bar>
      <xsl:return select="'bar'" />
   </bar>
</xsl:template>

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 />
</xsl:template>

should be allowed as a substitute for:

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

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 :)

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/



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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.