One could potentially have a code path using the latest JAXP XPath facilities to avoid requiring Saxon...

Of course XPath is a bit funny. Saxon's XPath does not return live nodes from the original DOM you hand to it. Xalan's does -- but ever since 2.1.0 has assumed that you're going to do a lot of XPath against each DOM without any changes. Thus ever since 2.1.0 Xalan has been incapable of any reasonable performance on a frequently changing, infrequently XPath'ed DOM (e.g. where you're using XPath to select DOM nodes and then modify them). Jaxen and JXPath were flakey as could be for "real world" XPaths (giving incorrect results in many critical cases) and didn't have JAXP compliant XPath APIs last I investigated.

XSLT is simpler -- Saxon currently rules. XSLT 1.0 is too limiting to justify continued use of Xalan.

Jess Holle

Jeremias Maerki wrote:
No. At runtime, FOP doesn't care what XSLT processor is used as long as
it's JAXP compatible. Inside the test code there's a hard reference to
Xalan for XPath processing. But that's unrelated to XSLT in general. The
runtime code doesn't have a dependency on Xalan.

On 05.09.2008 13:53:16 Philip V wrote:

I noticed that during the ant build of the trunk, Saxon is used. Since Saxon
is an xslt 2.0 processor, is there any plans to replace Xalan with Saxon as
the default processor with future releases of FOP?



View this message in context:
Sent from the FOP - Dev mailing list archive at

Jeremias Maerki

Reply via email to