I cant see how the updated document could ever be read by a running transform that has caused the update to occur. It seems to me that once a transform starts, it's source documents are frozen no matter what you do to them after the transform is running. If that weren't the case, the whole side effects problem is back and the basic philosophy of XSLT is out the window. 
 
Well, actually, if you do xsl:result-document (or xsl:document) to write an output file, you can actually get away with then reading the file using the document() function. It's technically undefined whether the document() function gets the file in the old state or the new state, but in practice you can get away with it. 

Or did I miss the whole point of this thread? 
 
I think the main point of the thread was using Saxon to execute XPath expressions against a DOM, not while it is changing, but before and/or after the application has made changes.
 
Michael Kay 

Roger

haexel@gmx.de wrote:
Is it possible to process a mutable DOM with saxon's 
xpath-api? 
      
Not without a new driver, which I've been meaning to write for a long
time but have never got around to. It would work just like the existing
JDOM driver. Any volunteers?
    
Maybe. Is a driver for Xerces DOMs similar to the JDOM driver(writing a
document
and a node wrapper)? I'll analyze the existing JDOM driver to estimate how
much 
work I'll have to do. What do you think about the effort?

thanks

haex



  

-- 
Roger Kovack
707-865-0807

------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ saxon-help mailing list saxon-help@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/saxon-help