Re: [exsl] Naming exsl:return/exsl:result (Was: Re: Fu

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