<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../make-menu.xsl" type="text/xsl"?><html>
<head>
<this-is section="extensibility" page="integratedfunctions" subpage=""/>
<!--
Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: Integrated extension functions</title>
<meta name="coverage" content="Worldwide"/>
<meta name="copyright" content="Copyright Saxonica Ltd"/>
<meta name="title"
content="Saxonica: XSLT and XQuery Processing: Integrated extension functions"/>
<meta name="robots" content="noindex,nofollow"/>
<link rel="stylesheet" href="../saxondocs.css" type="text/css"/>
</head>
<body class="main">
<h1>Integrated extension functions</h1>
<p>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 <i>reflexive</i> extension functions, and are described in later
pages.</p>
<p>From Saxon 9.2, this technique is supplemented by a new mechanism, referred to as
<i>integrated extension functions</i>. </p>
<p>There are several advantages in this approach:</p>
<ul>
<li content="para">
<p>You can choose any function name you like, in any namespace.</p>
</li>
<li content="para">
<p>The function signature is made explicit, in terms of XPath types for the arguments and result.</p>
</li>
<li content="para">
<p>There is no ambiguity about which of several candidate Java or .NET methods is invoked.</p>
</li>
<li content="para">
<p>There is less scope for configuration problems involving dynamic loading of named classes.</p>
</li>
<li content="para">
<p>All conversions from XPath values to Java or .NET values are entirely under user control.</p>
</li>
<li content="para">
<p>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.</p>
</li>
<li content="para">
<p>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.</p>
</li>
<li content="para">
<p>Integrated extension functions are more secure, because the function must be explicitly registered
by the calling application before it can be called.</p>
</li>
</ul>
<p>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.</p>
<ul>
<li>
<p><a class="bodylink" href="integratedfunctions/ext-simple-J.xml">Java extension functions: simple interface</a></p>
</li>
<li>
<p><a class="bodylink" href="integratedfunctions/ext-full-J.xml">Java extension functions: full interface</a></p>
</li>
<li>
<p><a class="bodylink" href="integratedfunctions/ext-fns-N.xml">.NET extension functions</a></p>
</li>
</ul>
<table width="100%">
<tr>
<td>
<p align="right"><a class="nav" href="integratedfunctions/ext-simple-J.xml">Next</a></p>
</td>
</tr>
</table>
</body>
</html>
