[this is the next part of my previous message - I accidentally sent it
unfinished]
In the context of the global variables, I was wondering about some function
call optimizations. Using the new attribute "explain" of Saxon, I've found
that, for example, inside the 'for' loops sometimes the function result was
computed only once and that result used within the loop body (if the
function had no arguments, for example,) however this does not work
globally. Is it possible to ensure that some functions ("constant"
functions that can be guaranteed to return always the same result,) are not
executed, unnecessarily, more than once, and instead the first result is
computed?
Regards,
Katarzyna Marszalek

I have stylesheet that, makes frequent use of a set of nodes. The set
depends on the input document, but does not change, once computed. Using
Saxon 7.3.1 I was setting a global variable to this set, and simply using it
throughout the stylesheet:
<x:variable as="element*" name="ALL-REACHABLE-DECS"
select="fn:all-reachable-decs()"/>
but version 7.4 prevents this possibility as it unsets the context when
entering the function. To get around this, I tried supplying the function
with the document root node:
<x:variable as="element*" name="ALL-REACHABLE-DECS"
select="fn:all-reachable-decs()"/>
<x:function name="fn:all-reachable-decs">
<x:param as="element" name="root"/>
<x:result as="element*" select="
fn:reachable-decs($root/key('elem-name-key','site'),(),true(),true())
"/>
</x:function>
but the result was following:
Offending expression:
function fn:reachable-decs
path
path
Node /
/
self::*
/
function key
string ("elem-name-key")
string ("webgen-site")
()
boolean (true)
boolean (true)
java.lang.IllegalStateException: Expression still has dependencies (64)
after reduction
Does this mean that I won't be able to precompute global variables in this
way?

Saxon 7.4 is available at http://saxon.sf.net/
The main theme for this release is stronger type checking, in accordance
with the XPath 2.0 draft. This means that function arguments are now
checked to be the correct type (rather than being implicitly converted),
and there are stricter rules for arithmetic and for comparison
operations. The benefits are that errors are detected earlier, and more
decisions can be made at compile time.
This still applies only to built-in types such as xs:integer, xs:string,
and xs:date - Saxon still has no schema support.
I would encourage you to declare types explicitly on variables,
functions parameters, etc: it gives the optimizer much more information
to work with, and helps to detect many errors in your coding.
XPath 1.0 backwards compatibility mode is implemented, and can be
switched on by specifying version="1.0" on any element in the
stylesheet, or xsl:version="1.0" on a literal result element.
There are two new diagnostic features you may find handy. Setting
saxon:explain="yes" on any stylesheet element gives you a compile-time
display of the compiled/optimized expression tree for any XPath
expressions on that element. And the -TJ command line switch gives you
detailed explanations of how calls to Java extension functions are fixed
up (or why they cannot be fixed up).
There's a full change log in the changes.html file, as usual.
Have fun!
Michael Kay