This assumes that the creation of nodes will be infrequent, to allow the overhead of temporary document + node creation to be insignificant. I was trying to manipulate all the text nodes in a largen document (in some cases between 7,000 + 10,000). I have since changed the model and am pre-processing + pipelining which is a significantly more efficient architecture, given the available solution.
Apologies for time-wasting by not noticing the documented restriction (RTFM!!). Rob Tice -----Original Message----- From: Joseph Kesselman [SMTP:[EMAIL PROTECTED]] Sent: 08 August 2002 14:02 To: [EMAIL PROTECTED] Subject: Re: extension function Documented restriction. Xalan treats the input document as IMMUTABLE, as is required by the XSLT processing model -- you must not, and if you're using our standard data model (DTM) you simply can not, alter it. That includes using calls like createElement. If you want to return a DOM Node to Xalan, create it using another implemention of the DOM such as the one provided by Xerces. (I suppose we could change Xalan's DOM proxy layer to forward create-node calls to another implementation -- but the problem then becomes "which one"? Xalan may be running with a parser other than Xerces, or with no parser. We could parameterize this, I suppose, or use reflection to try a few guesses ... but I'm really not convinced it's worth the effort. If someone wants to try to convince us otherwise, a good place to start would be to post this suggestion into Bugzilla as an Enhancement request...) ______________________________________ Joe Kesselman / IBM Research
