This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Designs for XSLT functions (Was: Re: RE: syntax sugar for call-template)
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)
- From: Uche Ogbuji <uche dot ogbuji at fourthought dot com>
- Date: Mon, 19 Feb 2001 10:23:20 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> Interesting thread!
>
> Here's another suggestion for the contentmodel of a hypothetical
> xsl:function:
>
> <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="..."/>
> </xsl:function>
>
> i.e
>
> <!ELEMENT xsl:function (xsl:param*, xsl:variable*, xsl:return)>
This is pretty limiting. I think the function body should have the content
model of a template.
> 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.
Yup.
> 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 ...
But if full template semantics are allowed, none of this is a problem.
Remember my example
<exsl:function name="my:func">
<xsl:choose>
<xsl:when test="$i-want-my-rtf">
<exsl:return>
foo
</exsl:return>
</xsl:when>
<xsl:otherwise>
<exsl:return select="'foo'" />
</xsl:otherwise>
</xsl:choose>
</exsl:function>
> 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.
Yes. I think "exsl:result" is the more properly declarative name.
> About calling functions: I vote strongly for positional parameters, as
> said before: consistent with other XPath functions, and most other
> languages too.
What about the idea of both? a positional static and a named dynamic
invocation?
--
Uche Ogbuji Principal Consultant
uche.ogbuji@fourthought.com +1 303 583 9900 x 101
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list