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.

From Saxon 9.2, this technique is supplemented by a new mechanism, referred to as integrated extension functions.

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. The full API is available for both the Java and .NET platforms; the simple API is available only for Java. The resulting combinations are described on the following pages.

• Java extension functions: simple interface

• Java extension functions: full interface

• .NET extension functions