Re: XSL processor authors - how about this approach?

Subject: Re: XSL processor authors - how about this approach?
From: "Tyler Baker" <tyler@xxxxxxxxxxx>
Date: Tue, 14 Mar 2000 12:22:54 -0500
----- Original Message -----
From: "Kay Michael" <Michael.Kay@xxxxxxx>
To: <xsl-list@xxxxxxxxxxxxxxxx>
Sent: Tuesday, March 14, 2000 5:26 AM
Subject: RE: XSL processor authors - how about this approach?


> > With the new MSXML processor (preview) you can create compiled XSL
> > stylesheet templates - pretty useful and fast.
>
> Most of the processors are now doing some kind of preprocessing of the
> stylesheet to create an in-memory representation that is efficient to
> execute, and reusable on multiple source documents. Whether this is
> correctly described as "compiling", I'm not sure: I doubt anyone is
> generating machine-executable instructions or even Java bytecodes. I don't
> think any product yet makes the "compiled" stylesheet persistent: that
could
> presumably be the next stage.

A long time ago in a galaxy far far away, I worked on an XSL Processor for
one of the earlier XSL drafts which precompiled the stylesheet into an
in-memory representation that was efficient to execute. Also, a complete
Stylesheet API was done so programmer's could change stylesheet properties
and add new styling nodes to the stylesheet at runtime if they chose.
Finally, after doing all of this, the Stylesheet could be printed back out
into its XML form or a more slightly more compact raw byte form which
incorporated use of Java object externalization. This was all done more than
a year ago. Since then the group I wrote the code for has since taken it
upon themselves to bring the code up to date with the current drafts.
Whether they still take advantage of these features and exploit them in the
user documentation, I am not sure. But at the time, I felt that making a
programmatically accessible stylesheet API had a lot of potential for doing
last second changes on the actual stylesheet that could not be statically
represented in a stylesheet. Some XSL implementations use a DOM Document to
represent the stylesheet tree, but I had found that this ended up being very
inefficient and error-prone for programmer's to mutate the stylesheet tree
in memory cause there was no type safety for enforcing the productions of an
XSL stylesheet other than trying to use a DTD to your best ability.

So this precompiling technique is nothing new to many XSL Processors, just a
lot of them choose to allow you to make a persistent form of the stylesheet
in many different ways. As to the idea of generating machine executable
instructions for a stylesheet would not do much at all as all the stylesheet
is nothing more than a set of processing criteria your stylesheet engine to
use for evaluating how to print out the source tree.

Tyler


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


Current Thread