Scott,
With regard to our upcoming integration work:
> Here's my proposal on how we should proceed:
>
> 1) Create a XSLTCMERGE1 (or whatever you want to call it) branch.
Sounds grand.
> 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.
I am just starting to have a look at your stuff now. At a first glance it
seems very much like our internal DOM - the DOM API and the way we create
iterators are very similar. I will get back to you on this as soon as I
am up to date on your code.
I like the way that the DTM builder class is separate from the DTM itself.
Have you any intention of creating mire DTD builders, such as your existing
DOM2DTM and SAX2DTM - for example a JDBC2DTM or an LDAP2DTM. Or would you
use an external 'box' to generate SAX events/a DOM from JDBC/LDAP?
> 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.
I think the best part of doing this is to add another abstraction layer
to our AST model. Let's take the <xsl:for-each> element as an example.
This element in handled by the xalan.xsltc.compiler.ForEach class,
this class extends the Instruction class, which again extends the
SyntaxTreeNode class:
(ForEach) --is_a-> (Instruction) --is_a-> (SyntaxTreeNode)
I suppose we only want to share the functionality that builds the AST
and that parses any patterns/expressions an element may have. The best
approach for sharing this code is to extract the bytecode-generating
code from the ForEach class:
ast.SyntaxTreeNode
|
ast.Instruction
|
ast.ForEach
/ \
compiler.ForEach process.ForEach
I suggest one general AST package that contains all the AST stuff up
to and including the parsing level, and then keeping the compiler and
interpreter stuff separate:
// XSL and XPath parsers
org.apache.xalan.ast.Parser
org.apache.xalan.ast.XPathParser
org.apache.xalan.ast.XPathLexer
// AST nodes
org.apache.xalan.ast.SyntaxTreeNode
org.apache.xalan.ast.Instruction
org.apache.xalan.ast.ForEach
// Compiler AST extensions
org.apache.xalan.xsltc.compiler.ForEach
// Interpreter AST extension
org.apache.xalan.process.ForEach
Does this make sense? It is just an initial thought, and I agree
with you that we should focus on the DOM/DTD integration first.
> 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.
My thoughts exactly. The input and output side should be the first and
easiest places to find common elements. The core functionality could
prove to be very different and should be left until a stage when we all
have a better understanding of eachothers code.
How does the Xalan core interact with the serializers? Translets use a
defined internal interface to send all its output to an output post-
processor (org.apache.xalan.xsltc.runtime.TextOutput - bad name, I know)
that removed duplicate attributes etc. and generates SAX events for the
final SAX output handler (we only support SAX output, as I am sure you
know already).
Morten
