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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: XSL processor authors - how abo, Kay Michael | Thread | Joining two trees, Matthew Cordes |
RE: Another newbie question, RSuiter | Date | Re: Another newbie question, Nicole Gustas |
Month |