Subject: Re: [xsl] Embedded Xsl From: Dipesh Khakhkhar <dkhakhkh@xxxxxxxxxxxxxxx> Date: Thu, 26 Feb 2004 12:33:12 -0500 |
Hi, Thanks for replying. I am using MSXML 4.0 processor. I am using command line utility provided by micrsoft to run it. You got it write, I am looking for something like this only whereby input file is loaded into memory only once and create a tree structure and i will use different stylesheet to get different output file. Each of my stylesheet refers a xml defination file. I am reading this using xsl:document. I have used vbscript to get uniqueIDS and date. Using saxon still desired output will be obtained keeping other things as it is or will there be major change in code ? After running and measuring time i came to know that processing part is not taking much time (it is showing in milliseconds from msxml command line utililty) but loading is taking plenty of time. Somewhere I found to use VB wrapper by loading xml into DOM and then running different stylesheets. Have anyone done like this and if yes any help will be highly appreciated. Will my code be transferrable to saxon processor easily considering i have written vbscript in my stylesheets. I hope i am not confusing but just trying to know how much effort and complicated will it be if i change my processor to saxon now. Thanks a lot for replyling. Regards, Dipesh Michael Kay wrote: The answer depends on which XSLT processor you are using. But most processor APIs provide some way of separating the parsing and transformation phases, so that you can parse a source document once into a tree in memory, and then transform it multiple times using different stylesheets. Doing the 7 transformations using different stylesheets is probably just as good as combining the stylesheets into one (which you could do, for example, using modes). In Saxon, one advantage of combining them is that you could re-use the indexes built to support keys. A caveat if you are using Saxon is that the obvious (portable) way to do this is to build a DOM first, and then supply the DOM as input to each of the transformations. But a DOM is much bigger and much less efficient than using Saxon's own tree model. I'm fairly sure that similar considerations apply to other XSLT processors too. Michael Kay XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Embedded Xsl, Dipesh Khakhkhar | Thread | [xsl] ignoring when transfor, Gill Shields |
RE: [xsl] Unable to resolve the XSL, Bob Cagle | Date | [xsl] CSS within XSL, Eric Selje |
Month |