Hello,
Last year, several Xalan-J developers worked on a prototype
implementation of the XSLT/XPath 2.0 draft recommendations based on the
Xalan-Java Interpretive processor. The work was carried out on the xslt20
branch of the xml-xalan module. Some preliminary work also began on 2.0
support for XSLTC. As the developers who worked on the xslt20 branch
began to focus on other projects, nobody was available to carry on that
work, so it has languished for some time. The work was based on older
draft revisions of the recommendations; that, coupled with bug fixes and
performance enhancements on the main branch, has caused the code on the
xslt20 branch to become badly out of date.
Over the past year, Xalan-J developers have placed a lot of emphasis on
improving XSLTC's level of conformance with the XSLT/XPath 1.0
recommendations. More recently, there's been a number of significant
performance improvements to XSLTC. The way things currently stand, it
looks like it would be better for future development of XSLT/XPath 2.0 to
resume on the XSLTC code-base. XSLTC has much better performance
characteristics than Xalan-J Interpretive, and it would be much easier to
add missing functionality to XSLTC than it would be either to continue
supporting and developing two very different processors in parallel,
thereby dividing scarce resources, or to develop only Xalan-J Interpretive
and try to catch up to XSLTC in terms of performance.
If there's significant continued interest in Xalan-J Interpretive, or if
there are things that could be done with the interpretive processor that
just can't be done with the compiling processor, we could look at reviving
XSLT/XPath 2.0 support in Xalan-J Interpretive. But in the short-term and
medium-term, I think that we're more likely to see this work succeed by
focusing on XSLTC.
Some groundwork for XSLT/XPath 2.0 support in XSLTC has already
begun. In particular:
. Morris Kwan has been adapting XSLTC to use the JJTree-generated XPath
2.0 parser, using the AST code contributed by Lionel Villard, that was used on the
xslt20 branch - the grammar from which that parser
is derived is generated from the same source as the grammar that appears
in the XPath 2.0 draft recommendation. Scott Boag is bringing the grammar
up to date with the current version in the latest XPath 2.0 draft.
. Christine Li has begun prototyping support for XPath 2.0 Functions and
Operators.
. Brian Minchau has begun to look at requirements for serialization in
XSLT 2.0.
. Joseph Kesselman and Myriam Midy have been working to adapt the Extended
Data Model (XDM) support from the xslt20 branch to XSLTC. That's not
really something that enables XSLT/XPath 2.0 support, but rather opens up
Xalan-J to accepting input from a wide array of sources.
Very shortly, we'd like to contribute those first pieces of code to
Apache, and publish a prelimary development plan to get us on the path to
XSLT/XPath 2.0 support. There should be plenty of work for all interested
parties!
In the meanwhile, I'd like to propose that we rename the existing
xslt20 branch to xslt20-interp, and that we create a new xslt20-compiled
branch on which we can develop XSLTC. It will probably take a fair amount
of time before the new development can replace the existing processors, so
I'd propose that we continue to maintain and develop the existing
XSLT/XPath 1.0 processors on the MAIN branch of xml-xalan. At some point
in the future, the community can decide whether to move the new XSLT 2.0
processor to the MAIN branch.
Questions, comments, endorsements and objections would be welcomed!
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro Xalan development
IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044
mailto:[EMAIL PROTECTED]
