Re: XSLT and XPath 2.0 development

[scott_boag]

One way to proceed might be to look at the interpretive version as a visitor of the same AST that the compiler uses.

The goal really is to collapse the amount of code that has to be maintained (and developed).

-scott

Lionel Villard <[EMAIL PROTECTED]> wrote on 08/28/2003 09:45:46 AM:

>
> >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