Project

Profile

Help

Forums » Help »

Are extension functions usually the wrong approach?

Added by Michael Staal-Olsen over 5 years ago

I am currently on a project that uses XSLT in order to transform a huge variety of XML documents. The solution is written in Java, and we are currently migrating from the Xalan XSLT processor to Saxon from Saxonica. Both processors allow us to write extension functions in Java which can be invoked in XSLT. We mainly use this for the purpose of loading GML geometries as JTS geometry objects, which we can then manipulate - for instance we can detect whether two geometries intersect. Is it possible to do something similar in “Vanilla” XSLT without Java extension functions? Whenever I have asked for extension function functionality of an XSLT processor on some Forum, it seems to me that a lot of people claim that the native function concept of XSLT 2.0/3.0 ought to make extension functions irrelevant. I guess my question is whether there are still good use cases for extension functions which XSLT does not handle in and of itself?


Replies (2)

RE: Are extension functions usually the wrong approach? - Added by Michael Kay over 5 years ago

There are several reasons that might justify the use of extension functions:

(a) the code already exists in Java and rewriting it in XSLT would be too much effort.

(b) the function requires complex data structures or algorithms that are not available in XPath/XDM. The situations where this arises are considerably fewer with XSLT 3.0 maps and arrays, but there are still some situations that arise, for example where bitmaps are used. Your example of detecting whether two geometries intersect might fall into this category.

(c) the code needs access to resources available using Java mechanisms - for example a SQL database, or a mail service.

In general though extension functions should be avoided unless there is a good reason for using them.

RE: Are extension functions usually the wrong approach? - Added by Martin Honnen over 5 years ago

I don't think XSLT 2 or 3 makes extension functions irrelevant, it is just that a lot of people moving from XSLT 1 to XSLT 2/3 do stuff in extension functions that can easily be handled by the richer type system and/or the richer function library and/or the user-defined functions and XSLT processing capabilities of XSLT 2/3, like e.g. regular expressions.

But a platform like Java certainly has functionality in the JRE you might want to use from XSLT if you have an XSLT processor written in Java. And of course third party libraries are also accessible and useful that way.

    (1-2/2)

    Please register to reply