Saxon

I painfully found out that implementing https://www.saxonica.com/html/documentation11/javadoc/net/sf/saxon/lib/ExtensionFunctionCall.html#copyLocalData-net.sf.saxon.lib.ExtensionFunctionCall- is important (but currently not taken into account in SaxonCS). On the other hand, I started with a Java example by Norm that didn't do it and seemed to get away with storing data in the FunctionCallDefinition class instead. I have so far not figured out whether that approach can break easily in e.g. Saxon EE and multithreading.

Firstly, for simple stateless "pure" functions, use the ExtensionFunction interface in preference to ExtensionFunctionDefinition/ExtensionFunctionCall. If you need the more complex interface, it's usually because you want to capture context information, and if you're doing that then you will want to make sure that each function-call expression appearing in your stylesheet results in a new instance of the relevant ExtensionFunctionCall being created.

However, if the only reason for using this API is because you want access to the dynamic context (e.g. the context item), then the ExtensionFunctionCall object doesn't need to hold any local data which means you can safely use the same ExtensionFunctionCall object each time. (But there's little performance benefit in doing so.)

As Martin says, if the ExtensionFunctionCall holds local data then it's important to ensure that the copyLocalData method is implemented.

To be honest, I'm reading the code right now and having trouble recalling why we actually need to copy the ExtensionFunctionCall object when its containing expression is copied. Historically it's probably because ExtensionFunctionCall implemented Expression , and an Expression can only have one parent in the expression tree, so it's always copied when doing things like function inlining. But I can't see why that applies to the ExtensionFunctionCall object.

Not simple !

I need to access to xPathContext.uriResolver, that's why I use the ExtensionFunctionDefinition.

Thanks to both of you for your responses, it largely simplifies my code !

Christophe