This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Re: xsl:function
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] Re: xsl:function
- From: Joe English <jenglish at flightlab dot com>
- Date: Wed, 21 Feb 2001 12:55:34 -0800
- Reply-To: xsl-list at lists dot mulberrytech dot com
> > > Finally, wouldn't it be useful for <xsl:function> to return multiple
> > > items? [...]
> > Actually I think it's pretty hard to encapsulate multiple values into
> > a single one in XSLT - how would you return a string, a number and a
> > node set without turning them all into an RTF? [...]
>
> It's already okay to have five <xsl:param> statements upon entry, so I
> figure: why should five <xsl:result> statements be such a big deal? A hacky
> suggestion: an RTF could be constructed, where the results would be
> (ordered) immediate children of the root. This wouldn't be necessaru if
> tuples existed in the language. Most annoyingly, the case where one value
> is being returned isn't very elegant. I'm not sure if it's possible to
> seriously suggest returning each result without a parent node connecting
> them (like an XML fragment).
Requirement 4.4 from [XPATH20REQ] "Should Add List Data Type to the Type System
of the Expression Language" would solve this and many other problems.
If list elements are latently typed, this might simplify things;
for instance the body of an <exsl:function> could contain the
same things as an <xsl:template>, along with <exsl:result>s.
Evaluating the function would return a list containing nodes
(from element instantiations) and primitive values (from <exsl:result>s).
[XPATH20REQ] <URL: http://www.w3.org/TR/2001/WD-xpath20req-20010214 >
--Joe English
jenglish@flightlab.com
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list