If I understand Joe's ideas correctly, the DTM separation work does not
iteract with the DTM encasulation. The DTM separation work does not change
the core DTM logic. The main changes are the moving of messages used by the
DTM code from the Xalan level down to the DTM level. None of the DTM
interfaces are touched by this change.
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 09:30
AM
Please respond to
xalan-dev
Uhm. I'm in the process of anaysing whether we can make DTM strictly an
internal representation, replacing Node Handles with flyweight "cursor"
objects, which would encapsulate both node access and document traversal.
The result ought to be more maintainable, more efficient when wrapped
around non-DTM data sources, and probably more efficient even when
accessing DTMs since it'd avoid the overhead of translating between Node
Handles and Node Indexes.
I'm not immediately sure how that interacts with Morris's proposal. I think
it may achieve many of the same results via a significantly different
route, fully encapsulating DTM rather than fully exposing it. If we're
really going to reconfigure DTM as a back-end representation, there may be
questions about whether the resulting API would be one we'd *want* to
expose.
The dtm jarfile is an interesting proposal, but we might want to shelve it
until we have a more solid proposal for what the cursor-based API would
look like and how DTM would be changed to better mesh with it.
______________________________________
Joe Kesselman / IBM Research
