[xsl] saxon:expression and functional argument issue ...

Subject: [xsl] saxon:expression and functional argument issue ...
From: Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 15 Jan 2002 14:22:22 -0500
I have to say I really like saxon a lot and I trust it so
much because I know Mike Kay is an active maintainer of the
XSLT standard. It's just great work.

But -- still recovering from our intense dynamic scoping
battle few weeks ago -- I can't resist noting certain
things that pertain to the discussion. Saxon:assign being
the most outstanding one of course, but here is another
little more subtle one:

> saxon:expression(string)

The supplied string must contain an XPath expression. The result of
the function is a stored expression, which may be supplied as an
argument to other extension functions such as saxon:eval(),
saxon:sum() and saxon:distinct(). The result of the expression will
usually depend on the current node. The expression may contain
references to variables that are in scope at the point where
saxon:expression() is called: these variables will be replaced in the
stored expression with the values they take at the time
saxon:expression() is called, not the values of the variables at the
time the stored expression is evaluated. Similarly, if the expression
contains namespace prefixes, these are interpreted in terms of the
namespace declarations in scope at the point where the
saxon:expression() function is called, not those in scope where the
stored expression is evaluated.

So really what expression does is to create a functional argument and return it. From that point on you can pass it into other functions to use it. But, here is the thing: any free variables in the functional argument are bound to the current value assignments at the time the funarg is executed. That means, it's as if all of those free variables have become implicit parameters to the lambda object produced by the expression function.

I do not want to convey any blame on Mike Kay at all, but to
the other side: in a world where serious XSLT processors offer
assignment side-effects, and functional arguments of a kind the
world hasn't seen since 1978 or longer, we should not hestiate
to put into place implicit parameters and funarg closures rigtht
into XSLT and strongly discourage XSLT implementors to add
assignment extensions to their processors.

regards
-Gunther

--
Gunther Schadow, M.D., Ph.D.                    gschadow@xxxxxxxxxxxxxxx
Medical Information Scientist      Regenstrief Institute for Health Care
Adjunct Assistant Professor        Indiana University School of Medicine
tel:1(317)630-7960                         http://aurora.regenstrief.org



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


Current Thread