The term extension function refers to a function that is available for calling within a stylesheet or query, but which is neither a built-in function provided by the Saxon processor, nor a user-written function written using XSLT or XQuery syntax within the stylesheet or query itself. For the purposes of this chapter, an extension function is a function written in Java or C# and made available to the Saxon configuration so that it can be recognized when compiling the stylesheet or query.
Extension functions, like other functions, are identified by name and arity. The name is a QName with a non-null namespace, which must not be a reserved namespaces, and should generally be the same for all functions in a function library. The arity identifies the number of arguments to the function.
Because extension functions are written in procedural languages such as Java and C#, they can have side-effects. An obvious example might be a function that sends an email message. A less obvious example would be a function that returns the next line in an input file (the side effect here is to change the current position in the file). The fact that functions can have side-effects is both a benefit and a danger. It's a benefit because it greatly increases the power of what XSLT and XQuery can achieve; it's a danger because it doesn't fit at all well with the functional and declarative nature of these languages, and can play havoc with optimization. Saxon tries to manage the problem of side-effects pragmatically, but if you want to create such functions, you need to be aware of the dangers.
Saxon provides a variety of APIs for writing extension functions, described in the following sections.
To write extension functions in Java, see Extension functions (Java).
To write extension functions in C#, see Extension functions (C#).