Currently we have no intention to build a separate dtm.jar. The DTM
separation work will make this possible. But we are not going with that
route at the moment. The separation will make it possible to build a
standalone xsltc.jar which includes the DTM code for the XSLTC_DTM branch.
Anyway, I don't see any requirement for a separate dtm.jar right now.
Sorry for not clarifying this in the original note.
Morris Kwan
XSLT Development
IBM Toronto Lab
Tel: (905)413-3729
Email: [EMAIL PROTECTED]
Joseph
Kesselman/Watson/ To: [EMAIL PROTECTED]
IBM@IBMUS cc:
Subject: Re: [Proposal] DTM separation
work
01/21/2003 10:46
AM
Please respond to
xalan-dev
> None of the DTM interfaces are touched by this change (of factoring DTM
out)
Granted... but *I* may want to change the DTM interfaces significantly, and
the result may not be something we really want other folks using. I'm
proposing we abandon node handles. That means abandoning most of the
current official public APIs of the DTM, and using the node-index based
calls instead... and leaving most of those as non-public, with the cursors
being the new public API. It isn't clear that the resulting revised DTM --
a specific back-end data model with no supported public APIs -- merits
having its own jarfile.
(Especially given how much trouble we already have explaining classpath
mistakes...)
I may be being excessively paranoid. But you did ask for opinions, and mine
is that
this is not the moment I would choose for a dtm.jar effort, since the
outlines of that module may be in flux and thus the benefit of a separately
reusable DTM is unclear.
On the other hand, cleaning up the dependencies between levels of Xalan
hierarchy strikes me a great idea.
______________________________________
Joe Kesselman / IBM Research
