AJAX and standards

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.

Although one of the basic techniques in AJAX is to use a JavaScript method called XMLHttpRequest, the applications I've looked at don't use XML at all (contrary to what the current Wikipedia entry would have you believe).  I wanted to try something like Google suggest for the VIAF project and wondered if it is possible to do that in standards-based way.

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" ?>
<cells>
    <language>eng</language>
    <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" />
</cells>

The style sheet turns this into a row of cells with captions:

Simple XML, and a whole lot better than a JavaScript snippet representing the same data structure, but really there's nothing to keep us from changing the 'language' tag to 'lang'.  Doing so wouldn't affect our application (presumably we would change the stylesheets at the same time), but might well break a different interface that tries to use the underlying service.

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.

--Th

Comments

[Bill Oldroyd]

You surprise me a little with this discussion.

Surely wrapping the SRU response with a stylesheet just increases the size of the response.

Stylesheets should be cached in the browser, which would not happen if the stylesheet is returned with the SRU response.

In our systems a typical SRU search returns the XML (10 records about 25K) and stylesheets for presentation of the metadata, standard page layout and code to text conversions (e.g. language codes).

Where the SRU request is returned by a database (as opposed to a gateway to Z39.50 say) the response time is very quick.

Bill

[Thom]

Yes, you would think the stylesheets would be cached. I'm sure it varies by browser and cache setting, but my experience is that they are not. At any rate, the possible extra bytes don't slow things down much, as there seems to be more latency time than transmission time for this size file.
--Th