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