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:
Hi,
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?
Thanks,
Phil
--
View this message in context:
http://www.nabble.com/Suport-For-Saxon-in-future-FOP-release-tp19329624p19329624.html
Sent from the FOP - Dev mailing list archive at Nabble.com.
Jeremias Maerki
