Two Ajax and XSLT Approaches: Transforming XML in Ajax with XSLT

Part 1 of this series 'XML processing in Ajax' introduced a problem
specification: to build a weather badge that can be inserted easily
into any Web page. The weather badge is constructed using Ajax techniques
and uses data provided by the United States National Weather Service
(NWS). That NWS data is provided in an XML format, updated every 15
minutes. This article installment looks at the second and third
approaches. These two approaches share one thing in common: they both
use XSLT. The XSLT language differs from many other computer languages
in that its syntax is valid XML. This can be a trifle confusing if
you're used to the C, Java, Perl, or Python languages. XSLT is a
language to query XML and transform XML into other formats. This is
precisely the problem I have with my weather data -- it's packaged
as XML, but I want something more user- (and browser-) friendly. And
the NWS data contains a lot more information than the weather badge
requires. Some technique is required to extract just the data items
I need. XSLT can handle both these requirements. As with other
programming languages, like Perl or Ruby, you execute XSLT by running
it through a language interpreter. This is often called an XSLT
processor. But XSLT is not a general-purpose programming language --
it exists to translate a single XML data file. So most XSLT processors
require two input files: the XSLT program and the XML file it
transforms... A third approach uses some elements of the first two
approaches. An Apache Web proxy brings the XML back to the browser for
further processing, and XSLT handles the actual translation from XML
to HTML. To invoke an XSLT processor inside a browser is more
computer-intensive than Approach 1, which merely accessed the needed
data elements directly from the DOM tree. For this simple example,
the extra compute time is unlikely to be noticed by the user. But if
the XML is large or the XSLT translation is complex, then the user
might notice an unacceptable delay while the browser churns out the
results. The flip side of this is that the code needed to manually
trudge through the complex DOM tree of a large XML file can lead to
JavaScript code that's difficult to write and more difficult to
maintain. You also need to consider the type of browser and computer
your users are running. Are these high-end workstations with memory
and processor power to spare? Or are they old, underpowered machines?
The answers to these questions determine if complex JavaScript XSLT
processing is a good idea for your application. More Information