>There is no formal interface that allows you to >supply a vendor specific source. Actually, I think there is. The DTM Manager class should be being selected at runtime based on a property in the environment. (See DTMManager.newInstance().) That can be overridden in the usual ways -- create a properties file which asserts your new defaults, or use the JVM's -D option, or set the property explicitly in your front-end code before calling the Xalan APIs. This would let you plug in your own DTMManager which supports additional kinds of Source and/or which routes the Sources to different DTM loading processes/implementations. I've done this on occasion when prototyping code, usually by either copying or subclassing DTMManagerDefault. DTMs (and therefore DOM2DTM's references to a DOM) persist as long as the DTMManager persists, unless the DTMManager is explicitly told to release them. The simplest solution to flushing the cache is simply to discard the higher-level Xalan transformer object and request a new one. DOM2DTM is designed for DOMs which will not be altered after their DTM proxy has been created. There's an experimental DOM2DTM2 class which maintains less local information and thus is able to track changes made to the DOM between transformation/XPath calls... but it requires some features that aren't supported by all DOMs, and we never finished cleaning it up and trying to make it performant. I believe our long-term approach is going to be something derived from the XDM sketch (at the document-model API level, anyway; the back end is likely to still be DTM in many cases). ______________________________________ Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more. "The world changed profoundly and unpredictably the day Tim Berners Lee got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
