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
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.
Is it possible to process a mutable DOM with saxon's
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
and a node wrapper)? I'll analyze the existing JDOM driver to estimate how
work I'll have to do. What do you think about the effort?
This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM +
LinuxWorld = Something 2 See! http://www.vasoftware.com
_______________________________________________ saxon-help mailing list