RE: Design Issues in XSLT

Glad to help!

One other suggestion is that you *may* achieve greater concurrency by
performing more smaller transforms than less larger transforms (break up
large input XMLs into smaller ones and maybe chain transformations).

Storing XML as trees in memory (such as DOMs) takes up lots of space.  You
*may* scale better if you pass other data containers around internally (such
as recordsets, collections or something you cook up yourself) and only enter
the world of XML at the periphery/interfaces of your application.

If you can use streaming APIs such as SAX then, potentially, you can greatly
reduce the resources required to perform some unit of work (compared to
working over trees).  (http://www.saxproject.org/?selected=event)

We find XSLT (in MSXML3) goes plenty fast enough for the work we've been
doing and we haven't had to pay much attention to optimizing the XSLT - the
bottle-neck usually lies elsewhere.

Usual caveats apply: one person's meat is another person's poison!

I'll leave my homespun wisdom at that - there are greater minds than mine
out there.  Good luck and have fun!

Adam


-----Original Message-----
From: Emmanuel Oviosa

Thanks Adam, thats the sort of response that I need, got anymore?


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list