Re: XML/XSL on the client for dynamic UI

[James Clark <jjc@xxxxxxxxxx>]

Stefano Mazzocchi wrote:

> It is. Cocoon is based on DOM and this requires all the stuff to go
> directly into memory. We all agree that DOM is the wrong approach for
> XML server side processing (like both James Clark and Mike Key have
> shown in their software) and event-based incremental operation is the
> way to go.
> 
> In fact, after the release of Cocoon 1.5, we are currently designing
> Cocoon2 which will be event-based and _much_ less memory consuming. The
> final goal is to be able to generate a 100 Mb database report using a
> few Mb JVM heap size. This also goes along with other efforts such as
> stylesheet compilation that is being implemented in XSL:P, the new
> incremental formatting API James Tauber and Mike Key are proposing for
> Fop and server side XML compiled pages for SAX-direct XML generation
> that removes parsing overhead.
> 
> Please, checkout the details on the web site.

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.

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,

- 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>

- tables of contents

- cross references (with the id function)

- numbering (with xsl:number)

Some of these are localized, but some are not.

If you want to process very large documents with a small JVM heap using
XSLT, the alternatives I see are:

- drastic subsetting of XSLT

- use a RandomAccessFile to provide random access to the XML document
without having to keep it all in memory

- use a multi-pass strategy

James



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