In my experience it would be better to focus on optimizing the current XSLT
implementations rather than try to build a Sax event driven system that
minimizes memory use/latency. It is definitely possible to build a system
like what you describe but its also a lot of work and no one has even
started building one as far as I know.

The latency problem would be minimized by simply making the current XSLT
implementations faster.

Some common techniques are:

1) improve the code efficiency of the existing implementations - everyone
works on this
1a) use a C/C++ based engine instead of Java - no implementation available
except for MS (draft syntax)

2) pre-load and pre-compile the stylesheet in memory  (most XSLT systems do
this)

3) compile the XSLT sheet to Java code - Saxon
3a) compile the XSLT sheet to C code - no implementation

4) combine 1&2 with schema analysis to reduce/eliminate pattern matching -
no implementation

5) event driven XSL transformation - no implementation

More general speed improvements can come by using something like JServ to
keep a Java VM in memory and preloaded with the XSLT engine and stylesheets.
Trying to run a XSLT processor from CGI would be painfully slow.

Jon Smirl
jonsmirl@xxxxxxxxxxxx



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