[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
RE: xslt and sax
Subject: RE: xslt and sax From: Kay Michael <Michael.Kay@xxxxxxx> Date: Mon, 20 Sep 1999 12:48:27 +0100 |
> - 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: xslt and sax, Jon Smirl | Thread | RE: xslt and sax, Kay Michael |
RE: Locate specific occurrence of e, Kay Michael | Date | RE: xslt and sax, Kay Michael |
Month |
Keywords