Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)

Subject: Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)
From: David.Rosenborg@xxxxxxxxxx
Date: Mon, 19 Feb 2001 17:47:36 +0100

Interesting thread!

Here's another suggestion for the contentmodel of a hypothetical

<xsl:function name="my:func">
  <xsl:param name="a"/>
  <xsl:param name="b"/>
  <xsl:variable name="c" select="..."/>
  <xsl:variable name="d" select="..."/>
  <xsl:return select="..."/>


<!ELEMENT xsl:function (xsl:param*, xsl:variable*, xsl:return)>

The content model for xsl:return should be the same as for
xsl:variable, allowing you to return arbitrary XPath values as well as RTFs.

The reason for allowing xsl:variable is an aid to split otherwise long XPath
expressions that would appear inside the select of xsl:return and to allow 
things like xsl:apply-templates and xsl:call-template to contribute to the
result even when it's not an RTF.

I think there is a major gotcha when only allowing a single xsl:return:
the lack of control structures in XPath. However, there is one in the
XPath 2.0 Req: 2.2. I would prefere to shoehorn such a construct into
XSLT 1.1 (!) rather than having a restricted mix (mess) of RTF and
<xsl:return> just to get to the control structures. This opinion is
strictly definition/implementation/optimization based. It's simply a
cleaner solution in my opinion. I have no idea of what possible
mess it would mean in terms of specifciation dependencies and
versioning though ...

Another thing: wouldn't <xsl:result> be a better name for <xsl:return>
(assuming it can only appear once)? At least to me it sounds more declarative.

About calling functions: I vote strongly for positional parameters, as
said before: consistent with other XPath functions, and most other
languages too.



David Rosenborg
Pantor Engineering AB

 XSL-List info and archive:

Current Thread