Xalan 1.1.0 Plans

[Scott Boag/CAM/Lotus <Sc...@lotus.com>]

I would like to do some restructuring of Xalan for version 1.1.0.  The idea
here is to untangle some of the spaghetti that has formed over the course
of it's evolutionary development.  Most of these changes center around the
xslt package.  What I would like to do is seperate out stylesheet data,
from construction of that data, and contextual runtime data.  The
repackaging would make Xalan look something like:

org
+---apache
    +---xalan
        +---client (existing Applet)
        +---extensions (redirect extension, etc.)
        +---processor (Construction of Templates/Stylesheets, i.e.
StylesheetHandler, etc.)
        +---templates (Stylesheet, ElemTemplateElement, etc.)
        +---transformer (Renamed XMLParserLiaison, reworked XSLEngineImpl)
        +---trace
        +---utils (was xpath.xml)
        +---res
        +---xpath
        ¦   +---dtm
        ¦   +---res
        ¦   +---xdom
        ¦   +---xml (backwards compat. exposed classes)
        +---xslt (Existing Interfaces, until TRaX)

The visibility schematic is as follows:
client  --> xslt, res
extensions --> xslt, res
processor --> xpath, utils, res, templates
templates --> xpath, utils, trace, res, transformer
transformer  --> utils, res, trace, templates
res --> -none-
utils --> -none-
xpath (and contained packages) --> utils, res
xslt --> processor, templates, transformer

The reason to do this, besides general detangling of spaghetti, is to make
the code more accessible for both the general public and for those of us
who have to deal with it every day.  In particular the separation of the
construction of the templates from the run-time of the templates, will help
us to do optimization which is currently difficult given the complexity of
the current approach.

In the course of this, I would like to take much of the code in
XSLTParserLiaison, and some of the code in XSLTEngineImpl, and combine it
into a Transformer object.  This will detangle a LOT of the spaghetti.  The
XSLTParserLiaisons will be kept around for backwards compatibility.

Having the flatter package structure should also do a lot to make the code
more approachable.  All in all, the overall goal is to make the code more
comprehensible to the person that does not spend their life working on it.

This approach will also be TRaX ready when the time comes.  Not sure if
TRaX will be ready for 1.1.0 or not.  I suspect it will end up being ready
for prototype implementation.

The downside of this is that it will end up breaking some people's calling
code.  I can keep basic interfaces backwards compatible, but folks who are
calling the more advanced interfaces in the guts of the code will have to
change their code when they upgrade.  I think this is a necessary evil for
aggresive evolution.

I think I'm just going to dive into this for a few days to see what
happens.  Frankly, I'm not absolutely sure what the end result will be...
it's a bit of an experiment.  I suspect it will take me about 5 to 10 days
to complete the work and check it in (if it turns out to be good).  I don't
think that doing this will destabilize the code too much, or be overall too
difficult, but I'll have to see when I get there.  If it gets too painful,
I'll just stop and reconsider.  In the mean time, I look forward to
people's comments.  If someone has strenuous objections, let's get the
discussion going right away before I get too far down the road.

-scott