A new way of implementing extension functions is available. These are known as
integrated extension functions. Unlike traditional extension functions invoked
as Java methods through reflexion, each integrated extension function is implemented as a separate class that extends the
abstract class net.sf.saxon.functions.ExtensionFunctionDefinition, together with a class that extends
net.sf.saxon.functions.ExtensionFunctionCall. The first class must implement a number of methods
providing information about its argument types and result types, while the second provides the call() method which
is invoked to call the function. A key advantage of this kind of extension function is that it can exercise
compile-time behaviour, for example saving information about the static context in which it is called, or
optimizing itself based on the expressions supplied in the function arguments. Another advantage is that you have
complete control over the function name, for example you can choose any namespace you like.
Integrated extension functions need to be registered in the Saxon Configuration. You can do this via the API, or (in Saxon-PE and Saxon-EE) via the configuration file. This means that in Saxon Home Edition it is not possible to use integrated extension functions when running from the standard command line interface.
The old way of binding extension functions ("reflexive extension functions"),
by mapping the namespace URI of the function name to a Java class,
is not available in Saxon Home Edition. Also, it has changed so that by default, it only recognizes namespaces using the
recommended format java:full.class.name. If you need to recognize arbitrary namespaces ending in the Java class name (as
allowed in previous releases on XSLT, but not XQuery), find the JavaExtensionLibrary by calling
Configuration.getExtensionBinder("java"), and on this object call setStrictJavaUriFormat(false).
The ExtensionFunctionFactory (which can be used to change the details of the calling mechanism for reflexive
extension functions, for example to perform diagnostic tracing) is now set as a property of the
JavaExtensionFunctionLibrary
or DotNetExtensionFunctionLibrary, rather than directly via the Configuration.
Under .NET, if an extension function expects a value of type XdmAtomicValue, it is now possible
for the calling XPath expression to supply a node; the node will be automatically atomized.
The factory mechanism for handling XSLT extension instruction namespaces has changed. Previously it was required
that the namespace URI should end in the Java class name of a class implementing the ExtensionElementFactory
interface. It is now possible to use any namespace URI you like. The namespace you choose must be associated with
the name of the ExtensionElementFactory class in the Configuration, which you can do programmatically
by calling Configuration.setExtensionElementNamespace(), or from the configuration file.
Element extensibility is not available in Saxon Home Edition, which also means that the SQL extensions are
not available.
