>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.
In my opinion, the main interest of the Xalan-J Interpretive is its uses within authoring tools, even though there are some features that are missing to be really usable in such environnement (no real AST for XSLT and XPath, no incrementality). In order to use XSLTC in authoring tools, we need to provide additionnal features, like incremental compilation and incremental execution, which I think are not so trivial to implement. I think it's easier to make Xalan-J interpretive simpler, to be less agressive in term of optimizations, to have a sort of "lightweight" implementation of XSLT targeting authoring tools only (or more generally tools that need to manipulate XSLT stylesheet without caring to much about execution performance), and to start really to think about incrementality (updating the target document when the *stylesheet* is modified, which is relatively easy to do, and not when the source document is modified, which is hard in the general case).
Lionel Villard
IBM Research
- XSLT and XPath 2.0 development Henry Zongaro
- RE: XSLT and XPath 2.0 development Rick Bullotta
- RE: XSLT and XPath 2.0 development scott_boag
- RE: XSLT and XPath 2.0 development Rick Bullotta
- RE: XSLT and XPath 2.0 development scott_boag
- Xerces / Xalan on PPC Udi
- Re: Xerces / Xalan on PPC Berin Lautenbach
- Re: XSLT and XPath 2.0 development Lionel Villard
- Re: XSLT and XPath 2.0 development scott_boag
- Re: XSLT and XPath 2.0 development Udi
- RE: XSLT and XPath 2.0 development Henry Zongaro
