>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

Reply via email to