Hi Morten. I think we are in synch for wanting to now move towards more
Xalan XSLTC integration. I am just unwinding from the DTM work (though we
still have a few nasty problems with extensions [Gary... I'll be working on
this over the next couple days.]).
Here's my proposal on how we should proceed:
1) Create a XSLTCMERGE1 (or whatever you want to call it) branch.
2) Work on moving DTM into the XSLTC stuff. There will need to be some
tweaking of the DTM to do this, but, for the most part, I think the
architecture is consistent with your DOMImpl. Some of the code was even
stolen directly from your DOMImpl.
3) I will work on replacing or rewriting org.apache.xalan.process and
org.apache.xpath.compile with the the abstract JCup/JLex and abstract
syntax tree stuff in XSLTC. Doing what ever it takes to merge the best
from both.
4) Once (2) and (3) are solid, merge back into the main branch.
After this, the next merge point should be the serializers, in my opinion.
> The most obvious is the compiler. 99% of all classes in the
> compiler is used to generate Java bytecodes. Even one such
> class may represent an <xsl:for-each> element, it shares no
> functionality with the Xalan code that handles the same
> element (except for element/attribute parsing).
Right. I agree with this. In my recent round to optimize Xalan, the
tooling stuff in Xalan is really an issue. It is clear that, at a certain
point, we want to draw the line with Optimization in the interpretive
version, and have that be for tools, diagnostics, and the like, and focus
most optimization efforts, like redundent expression evaluation (do have
any of this yet?) and optimizations that involve structural rewrites of the
code, to go into XSLTC.
> Parts of the runtime library may have some functional
> components that we can share, but other parts are merely
> extensions to the translet (or the AbstractTranslet base
> class) an very much tied to the compiled code in the translet.
Yeah, I think we'll have to take this on a point-by-point basis.
If we implement my plan above, I think that's a clear start, and then we
can move carefully and incrementally on other merge points. We have to be
very carefull not to compromise what XSLTC is trying to accomplish by any
merge points. I think we are both on the same page about this.
Open source contributers and potential contributers: Please send Morten or
me a note if you would like to become involved. This is some pretty
involved work, but it would be really great to have the collaboration.
Especially people who have compiler/parser expertise.
-scott
Morten Jorgensen
<morten.jorgense To: Scott Boag <[EMAIL PROTECTED]>
[EMAIL PROTECTED]> cc: xalan dev
<[EMAIL PROTECTED]>
Sent by: Subject: Xalan's stree & dtm
Morten.Jorgensen
@sun.com
06/14/2001 11:07
AM
Scott,
I have now finished the work with removing the temporary
DOM from XSLTC's compiler and removing the few bugs that
followed that work.
Now I want to focus more in Xalan/XSLTC integration, and
I want to start digging into the Xalan code. I still want
to focus on the input/output parts and on the internal DOM.
I have a million (or so) questions:
o) What is your internal DOM - stree or dtm or both?
o) Where can in find some detailed documentation on it?
o) What is the interface between Xalan in the internal tree?
o) Is the tree made up of arrays (such as with XSLTC and
Saxon) or are all nodes object (such as with W3C).
o) Is the database connectivity stuff a part of Xalan or
does it belong with a different project (Cocoon, etc.) ?
o) Where can I read more about this? The design docs are
unfinished, but what is there gives a basic understanding.
There are some parts of XSLTC that I want to stay completely
clear off, as they do not have a functional counterpart in
the original Xalan code.
The most obvious is the compiler. 99% of all classes in the
compiler is used to generate Java bytecodes. Even one such
class may represent an <xsl:for-each> element, it shares no
functionality with the Xalan code that handles the same
element (except for element/attribute parsing).
Parts of the runtime library may have some functional
components that we can share, but other parts are merely
extensions to the translet (or the AbstractTranslet base
class) an very much tied to the compiled code in the translet.
Morten
