> 1) PsychoPath is not "streamy" yet Nor is Xalan, really. We have some ability to do deferred loading of the document, but real streaming is one of those "always wanted, never got around to" projects. It's a _big_ challenge.
> 2) Type informations is not part of current interfaces. True. One would have to extend or replace the DTM interfaces to carry the additional data. There are a few sketches in the code suggesting possible ways to approach this, but again, we didn't have the resources to pursue them in the Xalan codebase. > 3) How would the XLST-to-bytecode (XSLTC) fit in? XSLTC runs against the same data model interfaces (DTM), and In Theory implementing compilation should just be a matter of generating code equivalent to what the interpreter is doing. In practice, it's a lot of detail work. > Ad 2: The DOM, NodeIterator and Schema interfaces aren't rich enough > for the type information we need in XPath 2 (and thus XSLT 2). Xalan currently runs on the DTM interfaces and data model. Those could certainly be extended to carry schema information. Work would also have to be done to replace the nodeset representation with something that could handle general Sequences (intermixed nodes and atomic values, possibly with schema types in both cases). An alternative might be to replace the DTM layer with a different abstraction. > Other than that, I would think that merging the two projects is not > required at all, Xalan-J should be able to simply consume PsychoPath Making that efficient will require converging the document models, I think. There are good reasons for not using an Object-per-node model like the DOM; storage size becomes a problem (Java objects carry a lot of baggage). DTM was a first cut at reducing that overhead, and in tuning the data model design for the needs of XPath, XSLT, and high-speed serialization. More could be done, but if you want performance you really want everyone to be talking the same language at the API level; adapters can be expensive unless everything is designed VERY carefully up front.