Re: XML/XSL on the client for dynamic UI

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