Fw: A weaker XSL?

Subject: Fw: A weaker XSL?
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Sat, 6 Feb 1999 13:31:02 +0200
>Michael.Kay@xxxxxxx wrote:
>> > How do I build a table of contents that is output BEFORE the document
>> > without reading the whole input before I start to output?
>> You can't, and that isn't my objective. What you can do, and what I
>> currently do with SAXON, is to perform a single serial pass of the input
>> document that simultaneously generates a TOC and the main rendered
>> on two separate output streams, then merge these together for
>> This is far more efficient with a large document than building the entire
>> document tree in memory or scanning it twice.

Is anyone here familiar with the 'm4' macro processor? Its a really ancient
one, but for one reason and another it hasn't been changed for years, its so
good :-) In 'm4', you can say:

... send stuff to stream <some-number> ...
... send stuff to another ...
undivert(<some-number>) - insert content of <some-number> stream here
... go on ...
... send stuff to nowhere ...
undivert(-1) - insert content of all streams in order

Etc. Now suppose we wanted XSL to work the same way. It would require some

- The for-all, apply-templates etc. would be limited to being called only
once in each <xsl:template>, and to accessing only descendents of the
matched node.

- Local constants would become vital; modes probably redundant.

- Some new constructs would be needed:

<xsl:create-list name="...">...</xsl:create-list>

Would create a new output list of nodes with some name, initialized to the
specified content, and currently not attached to anywhere in the result

<xsl:add-to-list name="...">...</xsl:add-to-list>

Would append nodes to the named list.

<xsl:insert-list name="...">

Would insert the contents of the list at the specified point.

I think this would allow doing anything XSL allows in a single SAX pass. As
long as the size of the temporary lists does not grow too much, this
approach would be _much_ more efficient then the current one, in both CPU
and memory consumption terms. Only when the temporary lists grow larger then
a DOM for the input document (seems unlikely), you'd be using more resources
then the current approach.

Stylesheets would become structured around the input instead of the output
of the stylesheet. I'm not certain whether this would be good or bad. But it
would be very different.

Hmmm. Maybe if this was _added_ to xsl, and a stylesheet could declare that
it satisfies the restrictions on 'apply-templates' etc. (<xsl:stylesheet
processing='stream'> ?), then an XSL processor could decide which
implementation scheme to use. Of course that would double the  complexity of
the XSL processor...

I think its too late in the game to go this way.

Have fun,

    Oren Ben-Kiki

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

Current Thread