PLEASE!!! When to use XSL and when DOM?

[charlys]

We are developing a Web-based application. We have a big dilema about which technology to use concerning the transformation of our huge XML data.

Some of us think about XSL and all its functionality for both displaying and transforming it, and some of us think we sould use the DOM for doing the "logics" and XSL only at the end for minor trnasformations and display.

We would really appreciate any founded arguments/opinion/advise about this issue

Thank you so much.

Charly

[eahmed]

Hi Charly,

XSL is a very powerful means for presenting data because you can work with it to now only format your data, you can also use it procedurally to (for example) make decisions, generate new data, iterate over collections, etc. The drawback to this approach is the 'language' itself. Although very straight-forward, it can take some time to get used to and formatting it can be a problem since white-space characters can be taken into consideration when the transformation is executed, resulting in tabs and spaces where you potentially don't want them (as a result of formatting the XSL file for readability).

Manipulating the DOM is also a great way to transform data but the big drawback here is that your code will be tied directly to what's in the XML file. If you're using XSL only the XSL file would be bound to the XML file making your code more generic and, therefore, reusable. Another drawback to using the DOM involves memory use since the DOM tree is built in memory before you have access to it - this can be a problem for large XML files if resources are limited. On the plus side, if you have the resources, you could cache the DOM and reuse it thereby increasing performance.

I recently wrote the CodeGuru Book Review and Newsletter archive sections based on using XSL and the DOM. It was straight-forward to implement once I got the hang of XSL and I extended the application to provide the capability to query the XML file before the resulting nodes are transformed into HTML using some involved XSL. I also did some caching in the Book Review section to reduce the load on the server so that it is not I/O bound in critical parts. These capabilities are provided by using the DOM along with XSL and implemented using JScript on the server in ASP pages. Here are the links to the sections: (Book Reviews) http://codeguru.earthweb.com/bookReviews/index.shtml (Newsletter archives) http://codeguru.earthweb.com/newsletters/index.shtml

For cases where the XML file is huge, and to further complicate matters for you (sorry), you could use SAX - the Simple API for XML. This is an alternative that is based on processing the contents of an XML file *as it is being parsed*. Basically, your SAX app would sit between the XML parser and the client. Using this method gives you the ability to, for example, build a DOM based only on nodes of interest instead of the entire XML file. MSDN magazine had a good article on this recently; here's the link: http://msdn.microsoft.com/msdnmag/issues/1100/xml/xml1100.asp .

I personally like to combine all three approaches, using SAX when working with large XML files to create a new DOM, then use the DOM to transform the resulting XML to HTML (or whatever) using XSL. Basically, I put the XSL-based transformation in the part of the application that I think will change the most over time, and use the other approaches as I move down from there (to the parts that aren't expected to change as much).


Good Luck,

Essam