Subject: Re: XML/XSL on the client for dynamic UI From: "Clark C. Evans" <clark.evans@xxxxxxxxxxxxxxxxxxxx> Date: Wed, 3 Nov 1999 10:47:12 -0500 (EST) |
On Wed, 3 Nov 1999, James Clark wrote: > I think it would be quite hard to do a full XSLT implementation that > didn't need random access to the whole document, at least for a large > proportion of stylesheets. I just finished a rather complicated XSL stylesheet which could be done with stream access, i.e. one-pass, limited heap. > There are many, many things that people commonly do in stylesheets that > cause an XSLT processor to access the document in a non-stream-like > way. For example, This is unfortunate, and I believe is mostly beacuse of the design of XSL. It could have been designed to be more "event" oriented rather than "procedural". The template matching mechanism is *so* pretty, pity the procedural mechanisms were added in and have now become dominant. > - xsl:sort > > - handling elements where the ordering of the children is not > significant, eg > > <xsl:template match="name"> > <xsl:apply-templates select="given-name"/> > <xsl:apply-templates select="family-name"/> > </xsl:template> These two are re-ordings. In most of the cases that I have needed, the elements requring re-ordering is but a small fraction of the document size. An alternative would allow for multiple output streams, with a feedback mechanism; so that the output of a first stage can be fed back into the system for a second stage. For many cases, an aggregator combined with a hash table would do the trick. > - tables of contents This can be done with multiple streams, have one output stream be the document and the other result stream be the table of contents. This is the classic SAXON bible example. > - cross references (with the id function) > > - numbering (with xsl:number) > > Some of these are localized, but some are not. Yep! In the case of a cross reference or index, a string oriented aggregator could be used (concatination instead of addition). > If you want to process very large documents with a small JVM heap using > XSLT, the alternatives I see are: > > - drastic subsetting of XSLT Yes, but it would handle 80% of all XPATH cases. 75% of my cases are limited to the ancestor and attribute axis, and an additional 10% can be obtained by adding access to childless-children. This leaves 15% of my cases, which could have been implemented with a feedback stream combined with an aggregator. > - use a RandomAccessFile to provide random access to the XML document > without having to keep it all in memory This is just a particular type of DOM implementation. > - use a multi-pass strategy Yep... only multi-pass based on the output of a previous stage processor. I wholeheartedly believe that a combination of the "drastic subsetting" and "aggregator/feedback-stream" would do it. What is your candid thoughts? If I could find someway to fund a stream-based XSL processor (using a limited syntax) would you think it would be useful to research? Thanks! Clark XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XML/XSL on the client for dynam, James Clark | Thread | Re: XML/XSL on the client for dynam, Sebastian Rahtz |
Re: XSL, Steve Muench | Date | RE: XML/XSL on the client for dynam, Kay Michael |
Month |