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 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] RE: syntax sugar for call, Michael Kay | Thread | Re: [xsl] RE: syntax sugar for call, Clark C. Evans |
Re: [xsl] Re: Reliance on import pr, Jeni Tennison | Date | Re: [xsl] Transforming HTML to NITF, Jeni Tennison |
Month |