XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (688 page)
Read XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition Online
Authors: Michael Kay
Binding by Namespace in Java Processors
Most of the Java XSLT processors (Saxon, Xalan, jd.xslt, Oracle, xt) support an implicit binding of extension functions to Java methods, based on the idea that the namespace URI used in the function identifies the Java class, and the local name of the function corresponds to the method name. Xalan-J (which refers to this approach as the “abbreviated syntax” for extension binding) also allows the namespace URI to represent a Java package, leaving the local name of the function to represent both the class name and the method name.
For example, the following stylesheet can be used in Saxon to calculate a square root.
Example: An Extension Function to Calculate a Square Root
This example shows a stylesheet that returns the square root of a number in the source document.
Source
The source document is
sqrt.xml
:
Stylesheet
The stylesheet is
sqrt.xsl
.
This stylesheet calls an external function
Math:sqrt()
, where the namespace prefix
Math
is bound to the namespace URIjava:java.lang.Math. Saxon recognizes namespace URIs beginning withjava:as special—the part of the URI after thejava:is interpreted as a Java class name. The processor loads this Java class (which must be on the classpath) and looks to see whether it contains a static method calledsqrtthat can take an argument that is a double. It does, so this method is called, and the result is taken as the return value from the function call.
xmlns:xsl=“http://www.w3.org/1999/XSL/Transform”
xmlns:xs=“http://www.w3.org/2001/XMLSchema”
exclude-result-prefixes=“xs”
version=“2.0”>
xmlns:Math=“java:java.lang.Math”/>
Output
Although each of the Java XSLT processors supports implicit bindings of Java methods to extension functions in much this kind of way, the details vary from one processor to another, and it may be difficult to write code that is completely portable across processors. In particular, processors are likely to vary in how they map between the XPath types and Java types. This is especially true if the Java class contains several methods of the same name, but with different argument types (method overloading). To find out the detail of how each processor handles this, you will need to consult the documentation for your specific product.
Most of what I've said so far about extension functions applies equally to XSLT 1.0 and XSLT 2.0. In fact, most of the processors mentioned do not yet have an XSLT 2.0 version. So it remains to be seen how vendors will tackle the challenge of mapping the much richer type system in XSLT 2.0 to Java classes.
Most of these processors allow a call on a Java method to return a wrapped Java object, which can then be supplied as an argument to another extension function. For example, you might have a function
sql:connect()
that returns an object of type “SQL connection,” and another function
sql:query()
that accepts a SQL connection as its first argument. In XSLT 1.0, with its limited type system, this object is generally modeled using a single extra type “external object.” With XSLT 2.0, it is possible to go further than this and implicitly import any number of user-defined types into the stylesheet. Saxon takes this to its logical extreme, and implicitly imports the whole of the Java class hierarchy, mapping class names into the namespace
http://saxon.sf.net/java-type
. The result is that (assuming the prefix
class
is bound to this namespace) you can declare a variable such as: