RE: xslt and sax

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

Well, a "DOM-like" object is closer to the truth. 
> 
> 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.

yes, it's possible. Earlier releases of SAXON had a "Serial Stylesheet"
concept that worked like this. It didn't work by waiting until the required
part of the document was available, rather by failing if you used a
construct that required lookahead. I dropped it from the most recent
releases because it was making the code too complicated.

I'm hoping to take a fresh look at ways of handling large documents in a
future version of SAXON. Currently I'm thinking in terms of a filter that
breaks up the document into subtrees and presents them to XSLT one at a
time, with the ability to stitch the results back together again using the
document() function.

Mike Kay


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