Update and improve transform and XSLTransformer processes #34

rolfl opened this Issue Sep 13, 2011 · 1 comment


None yet

1 participant

rolfl commented Sep 13, 2011

So, I think I will tackle the last remaing chunk of code (transforms), and come back to the XPath later.... (Wednesday?)

If you're looking at transform, it would be nice to see whether the interface to Saxon can be improved. At present, I think Saxon is being presented with a SAXSource and SAXResult so the JDOM source tree is reconstructed as a Saxon tree. Since Saxon is able to transform JDOM input directly, this is pretty inefficient.

Using Saxon to deliver XPath 2.0 access, as an alternative to Jaxen, would also be quite feasible.

(Also note: the Javadoc for org.jdom.transform.XSLTransformer is looking very dated.)

Michael Kay

rolfl commented Feb 1, 2012

JDOM does indeed convert the JDOM content to a SAX stream, which then in turn is passed to the Transformation engine, which then feeds the results (using another SAX stream) back to JDOM.

This is a very low-level transformation, and as a result is reliable and portable.

It is not very efficient though.

Having inspected this from a few perspectives I think that:

  1. correct support for Saxon (or any other library) would likely require that library to be available at compile time, and that is not an nice requirement.
  2. Using the SAX interface is portable, and can be used for 'any' library.
  3. There would be no need to change the API to add support later so there is no need to force this in to JDOM2

For the moment (JDOM2) this does not need a change to this interface to make it work with other libraries. If anyone is motivated enough they can implement a specific alternate source to get it done.

This is going to be deferred for the moment. Please mail the mailing list or comment on this issue if you have ideas, patches, complaints, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment