Re: XML/XSL on the client for dynamic UI

[Stefano Mazzocchi <stefano@xxxxxxxxxx>]

James Clark wrote:
> 
> 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.  

What you say is (of course) correct. XSLT was not designed to be
incremental what you outlined below clearly shows why.

Please, don't get me wrong our goal is to come up with an XSLT processor
than can work incrementally as much as possible.

For example,
> 
> - xsl:sort

For example, let's say you have a SQL generated XML document. You could
do sorting on the XSLT level or you can do sorting on the SQL level.
Once you know the differences in terms of speed, you'll do what you like
the most, but the processor should _assume_ you are able to do
incremental operation.

This goes along with stylesheet compilation: stylesheets will be
compiled into direct code that will know what to do, adapting on the
particular needs required.

Of course, is xsl:sort was choosen, no matter what you'll have to store
the baby in memory, but I don't consider this a limitation but a user
choice.
 
> - 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.

Right. As I said, we'll try to be as fast as possible and will clearly
say that using such functions _might_ slow things down because of the
broken incremental operation.
 
> If you want to process very large documents with a small JVM heap using
> XSLT, the alternatives I see are:
> 
> - drastic subsetting of XSLT

No. We'll support the full XSLT spec.

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

Might be a solution for very big files where JVM heap is really an
issue, but I wouldn't use it on a regular basis (disk access could be
real bottleneck)
 
> - use a multi-pass strategy

Hmmm, very nice suggestion, James, worth investigating further...
 
-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@xxxxxxxxxx>                             Friedrich Nietzsche



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