>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?
Either approach is viable. Exporting as SAX and running that into SAX2DTM
would certainly be the easiest thing to code, but might not be most
efficient (which is why we also did DOM2DTM).
Note that these should probably be considered implementations of the API
rather than just builders -- both because their internal representation
varies significantly (though they share a great deal of code from their
common base class) and because we may wind up doing other versions which
have the same API but different internals. For example, there's been some
interest in reviving the old ultra-compact version of DTM and making it
available under the new APIs; that would be slower but should allow us to
handle larger documents in a given amount of memory.
Re the abstract syntax tree:
>I suppose we only want to share the functionality that builds the AST
>and that parses any patterns/expressions an element may have.
And any stylesheet optimizations which can be performed at that level, of
course. One of the things I'm Really Hoping is that we can share as much
cleverness as possible between the two paths to execution.
>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:
Sounds like a Plan...
>How does the Xalan core interact with the serializers?
Generally, standard SAX. We do generate some Processing Instructions which
are intended to provide directives/hints to the serialzer, counting on the
fact that XML consumers are supposed to ignore PIs which aren't relevant to
them; if that bothers anyone, a SAX filter could be dropped into the path
to remove them.
