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

Re: Designs for XSLT functions (Was: Re: RE: syntax su

Subject: Re: Designs for XSLT functions (Was: Re: RE: syntax sugar for call-template)
From: Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>
Date: Mon, 19 Feb 2001 10:23:20 -0700
xsl return
> 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@xxxxxxxxxxxxxxx               +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


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.