> > If I were to write an xslt processor from scratch, I'd either drop DTM > > altogether, or have the transformation work on some interface which can > > be provided from both DOM and DTM. I'd also try to get some closer > > integration between the xslt interpreter and the xsltc compiler, i.e. > > have a bunch of classes, each with methods compile() and interpret(), so > > people could more easily ensure they perform the same operations.
I believe there is a sketch of a "document cursor" abstraction, called XDM, checked into the Xalan repository. Our plan had been to migrate Xalan to running over XDM, making DTM strictly a back-end representation and allowing an XDM that ran directly over the DOM rather than the current kluge of wrapping DOMs in a partial DTM. This would also make plugging in other data models easier, if you wanted to run across JDOM (ugh) or some custom model used by a particular application. I did some additional (unpublished) work on XDM before setting it aside, so I can attest that the approach is viable. Retrofitting it into the processor would not be a small task -- it's on the same order of magnitude as the work we did rewriting XSLTC to share DTM with the interpreter -- but would certainly be doable. The result would be a somewhat cleaner architecture.
