Note that XSLTC, as currently implemented, is paying a fair amount of
overhead in its use of DTM due to remaining dependencies on the DOMImpl
adapter layer... which is the single largest reason it's using its own
magic XSLTCDTMManager rather than a standard DTMManager. One of the things
I'm hop
espond to xalan-dev
To: [EMAIL PROTECTED]
cc:
Subject: Re: Support for plugging in alternative DTM implementations in
XSLTC
Note: If/when we're ready move to XDM, this support should go at *that*
level, and the question of selecting DTM implementati
Note: If/when we're ready move to XDM, this support should go at *that* level, and the question of selecting DTM implementations will be subsumed by the choice of which XDM implementation you use.
__
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL
I would like to add that checking all those files on every transformation
is even much more expensive on OS390 ( IO, opening and closing is really
expensive on OS390). According to some measurements It could result in 100
? 500% performance degradation.
Igor Hersht
XSLT Development
IBM Canada
Hello,
Today, Xalan-Java Interpretive uses the
org.apache.xml.dtm.DTMManager.getInstance() method to create a DTMManager
object for a transformation. That method uses the
ObjectFactory.createObject mechanism to create an instance of a
DTMManager. That will look up the name of the select
