For a long time now we have wanted to embed searches of other people’s collections of stuff into the Engineering Subject Centre‘s website. The general idea is to let people look at those collections without leaving our site, which may or may not be sensible. In one case doing so would allow us to use a remote repository service (the Jorum) to host resources that we want to help make available, saving us the cost and risk of managing the repository while showing the close relationship that we have with this material. With the help of our friends at the Jorum we have been experimenting with a light-weight approach to using the SRU (search and retrieve by URL) standard to achieve this.
SRU is a bona fide library standard for remote query, drawing on the venerable Z39.50 but updated for the modern world of the web and XML. Perhaps surprisingly given its pedigree, SRU is pretty straightforward. You encode your query, stick it at the end of a URL and GET an XML encoded result set (or error message). A typical URL will look something like
You can cut-n-paste this into you browser URL bar (without line breaks or spaces!) hit return and see what some typical results look like, in this case from the Library of Congress voyager service.
You can see my effort at adapting this for something like the task we want to do at my SRU Test Search page. Do take note that it is pointing to a Jorum server that is used for testing and development, not the production server, so sometimes it is deliberately broken. If you’re interested my source code is all collected in one zip file. You’ll soon see why I don’t earn a living by programming.
Some reflections on doing this:–
- SRU is as simple to implement as you could hope.
- Writing an XSLT to get the returned list of LOM records into XHTML wasn’t so simple. Actually, it’s not the LOM stuff that’s difficult or the SRU response XML (I don’t think RSS-formatted responses would help), it’s doing stuff like pagination, where getting the XSLT to test whether there is a next page to display is mind bending. Perhaps that’s my inexperience with XSLT showing.
- There is something of a gotcha in the Intrallect approach: the XSLT file has to be served from the same domain as the XML file it acts on. This is a security measure implemented by browsers because of phishing scams and the like. Clearly, you’re not always going to be in the position where the repository manager will play host for you in this way. The way around this was to write a simple Perl CGI script, that takes the query from the web form and sends it on to the SRU service, when it gets the reply echos it to the browser. That way both XML and XSLT files come from our server. Fortunately the Perl cgi-lib and LWP libraries make this pretty simple.
- One gotcha left in my XSLT is that I assume that the repository echos the query you sent back in the XML response. This is optional in SRU, and at least one other repository that we would like to search doesn’t implement
In conclusion, SRU offers a standard, professional yet simple means of embedding query of a remote repository or catalogue into a website (e.g. a VLE), though you might find some of the result-handling needs thinking about.