Re: Embedded Xsl

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