[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XSL processor authors - how about this approach?
----- 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|