I've just discovered and used an application of the Xalan extension mechanism, namely scripting XSL with Python. In hindsight, the technique seems quite trivial, but I didn't quite realize all the implications until now. Using Java methods as extensions is an alternative too, of course, but requires significantly more complicated steps in deployment, and, as Java is quite a static language, re-compiling and re-installing classes.
In contrast, Python extensions are just as dynamic as, well, Python scripts in general. In the most simple scenario, one just updates the XSL stylesheet and its embedded Python functions and does nothing more. Even in the more complicated use scenarios, updating the code is rather trivial.
To use Python with Xalan, you need two libraries: bsf.jar and jython.jar, Bean scripting framework and Jython implementation, respectively. There's a catch, though. The bean scripting framework was originally implemented at IBM, but was later donated to Jakarta Apache project. Now, the current distribution of BSF at Jakarta is complete, but it seems that they've changed the package names to correspond the current maintainer, org.apache.bsf etc., but recent implementations of Xalan live in the past and expect the BSFManager and BSFEngine to be in package com.ibm.bsf.
So, if you just use the Jakarta's bsf.jar and standard jython.jar (and put them in the classpath), you will probably see a longish stack trace, complaining something like this:
