This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: [exsl] Naming exsl:return/exsl:result (Was: Re: Functional programming in XSLT)
Jeni Tennison wrote:
>...
>I think we need an imperative term that doesn't imply that the
>function terminates. exsl:result-in, exsl:fix-result,
>exsl:set-result... others?
>
Not sure why you say 'imperative'.
I think we need to forget that this element is specifying the result
of a function - we know that because it's in a function body . The
reason we need an element at all is that we want alternatives to
returning an RTF. Colin Muller suggested exsl:value-of which seems
along the right lines, except of course there is already xsl:value-of.
If I am reading the EXSL proposal correctly a function body containing
<xsl:value-of .../> would return an RTF containing a text node,
whereas <exsl:value-of .../> would be returning potentially any sort
of object, say a string. To use the same name would be confusing
IMHO.
So, what about simply exsl:object? Or, if we need to explicitly
convert to a type, exsl:string, exsl:node-set, exsl:boolean? <aside>
Apart from anything else this will help those with an imperative
language background to resist the temptation to put <exsl:return /> at
the end of a nicely constructed RTF.</aside>
This would maybe help with the discussion about what it means to have
more than one 'result' declaration. To end up with a result with more
than one exsl:boolean in it is obviously wrong, as is a mixture of
types (probably). But maybe having several exsl:strings is OK: the
return value is formed by catenation.
In implementation terms maybe you always build an RTF-like structure,
with special nodes to determine how it should be converted to a
specific type.
rename xsl:value-of to xsl:string anyone??
Can one put these things inside an xsl:variable, and then return the
variable?
Regards,
Trevor Nash
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list