Integrated extension functions

There are two ways of writing extension functions. The traditional way is to map the name of the function to a Java or .NET method: specifically, the namespace URI of the function name maps to the Java or .NET class name, and the local part of the function name maps to the Java or .NET method name. These are known as reflexive extension functions, and are described in later pages (use of these requires Saxon-PE or Saxon-EE).

Since Saxon 9.2, this technique has been supplemented by a new mechanism, referred to as integrated extension functions (available in all Saxon editions).

There are several advantages in this approach:

• You can choose any function name you like, in any namespace.

• The function signature is made explicit, in terms of XPath types for the arguments and result.

• There is no ambiguity about which of several candidate Java or .NET methods is invoked.

• There is less scope for configuration problems involving dynamic loading of named classes.

• All conversions from XPath values to Java or .NET values are entirely under user control.

• The function implementation is activated at compile time, allowing it to perform optimization based on the expressions supplied as arguments, or to save parts of the static context that it needs, such as the static base URI or the current namespace context.

• The function declares its properties, for example whether it uses the context item and whether it has side-effects, making it easier for the optimizer to manipulate the function call intelligently.

• Integrated extension functions are more secure, because the function must be explicitly registered by the calling application before it can be called.

There are two ways of writing integrated extension functions: the simple API and the full API. Both interfaces are now available for both the Java and .NET platforms (the simple API for .NET is available since 9.9.1). The resulting combinations are described on the following pages.