Re: [xsl] functions and XSLT

["Dave Gomboc" <dave@xxxxxxxxxxxxxx>]

> XSLT templates can only create result tree fragments. An important
aspect of
> user defined functions is the ability to return arbitrary XPath
values, including
> node sets. That's the main reason why it's not sufficient to use named
templates.
>
[snip]
>
> The problem is that it cannot *return* nodes comfing from, for
instance,
> the source tree. It can only *create* new nodes. New nodes has their
> own base URI for example. In XSLT 1.0 this is the URI of the
stylesheet,
> in XSLT 1.1 you can change this by xsl:base but it wouldn't solve the
problem
> in general.

I understand that people are saying there is a large distinction between
providing a return value and creating a result-tree-fragment.  I just
don't see that two types of subroutine are required to allow these roles
to be distinguished -- to me, the latter issue can and should be
orthogonal to the former.  The unit of subroutine should be focused upon
computing the appropriate information and returning it.  Exactly _how_
that information is used later -- whether that be within an XPath
expression, or written out as a tree fragment -- need not (and
therefore, should not!) depend upon the internal definition of the
subroutine, but rather only upon the context in which the subroutine is
referred to.

Regarding source nodes, the inability to return a source-tree-fragment
reflects the lack of a construct allowing the construction of closures,
rather than an inherent, deep-seated flaw in the template mechanism.

Regarding the return of boolean values, these can be handled just as
numbers are, by an intermediate coercion to string.  If it is felt
necessary, syntactic sugar could be defined to rid us of any perceived
goopiness here (though frankly, XSLT is already an angle-bracket soup to
begin with! :-)

Dave Gomboc



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list