[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

xslt and sax

---

---

i think i might have asked this question before, but didn't
get any takers.

this time i'm a bit clearer i hope:

- it appears that all the xslt processors out there want to have
a DOM object for both the document and the stylesheet. (right?).

- there are DOM implementations that will sit on top of SAX, but
they still take the approach of sucking in the whole document in
one go -- the DOM client (the xslt processor) won't do anything
til the whole thing is read in. (right?).

- an xslt stylesheet does have to be read in its entirety before
any processing can be done (a new template might show up, etc.).
in general, the document might have to be read entirely as well
(processing of the first element might be conditional on the existence
of some element that only shows up at the end). Not only that,
but arbitrary look-back might also be necessary (say, if there are
two "for-each" clauses over the same tree). (right?).

- however, it should be possible to engineer a combination of an
xslt processor and DOM implementation that can start processing
document instances before they have entirely been read in.
it would just stall if there were a test or select requiring
looking forward -- but would not stall if there were no such tests.
The system could also be configured to cache already-read nodes or not,
dependent on whether look-back is necessary. (right?).

The primary goal here is to allow greater concurrency in a processing
pipeline, so that transformation can commence before results are
completed. A secondary (but distinct) goal is to allow xslt processing
without ever having to hold the entire document instance in memory,
at least for some stylesheets. But right now I'm more worried about
latency than RAM.

Thanks....

-mda


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

---