This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

saxon:expression and functional argument issue ...


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@regenstrief.org
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]