The initial impetus for changing to AJAX for Web applications is to improve the user experience by avoiding screen refreshes and increasing the speed of interaction. Another benefit, however, is that others can take the services your application is built on and build new ones. I reported earlier on an experiment by Mike Teets with Google maps. His first prototype broke after two days because Google changed something in their implementation. This is the sort of thing that an implementation based on standard protocols would help avoid.
One reason why XML is often avoided is that processing XML retrieved with XMLHttpRequest with XSLT stylesheets can be difficult to do across browsers. I avoid that by using an HTML iframe that can accept a URL, retrieve the XML document and apply any associated style sheets, all in a fairly standard way (i.e. it works in IE and Firefox). The Dewey Browser works this way. Here's the XML sent to the browser for the first row:
<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet type="text/xsl" href="/ebooks/xsl/ddc3.xsl" ?>
<cell ddc="0" count="15146" />
<cell ddc="1" count="4911" />
<cell ddc="2" count="3434" />
<cell ddc="3" count="38114" />
<cell ddc="4" count="1530" />
<cell ddc="5" count="7705" />
<cell ddc="6" count="29844" />
<cell ddc="7" count="3915" />
<cell ddc="8" count="12156" />
<cell ddc="9" count="9372" />
The style sheet turns this into a row of cells with captions:
In my earlier post I reported the problems I had in using SRU for fast retrieval (tenths of a second). In addition to the length of the records I was retrieving, the associated CSS and XSL stylesheets files needed all slowed the interaction down unacceptably.
At first I rejected the trick of wrapping the XSL file around the XML data to avoid further HTTP interactions, but Ralph LeVan, our SRW/U expert, pointed out that this isn't that much different from wrapping an SRU response with a SOAP wrapper to get an SRW response. By doing this (and embedding the CSS style commands too) a single interaction gets an XML file ready to display in the browser. Further, by reducing the information down to only the fields needed for the quick display, the response is only about 7,500 bytes (including the style sheet), rather than something approaching a megabyte in my first SRU experiments. Coupled with a hash-table based search engine, the system can return results in 0.01 seconds on my workstation. When the network gets involved things slow down, but I still see 0.4 second response times, even using VPN over a cable modem from home.
And the whole thing looks very standard. Throw away the stylesheet the data is wrapped in, and you've got a standard SRU response using a subset of XML MARC for the data. The request is standard SRU, too, so it would be quite easy to build a different interface, and have some expectation that the API you are talking to isn't going to change overnight on you.