IL2005 Question Followup

I’ve been thinking about a question I was asked during my presentation at IL2005. More specifically, I’m unhappy with the answer I gave to it.
In response to my call for ILS vendors to provide SOAP interfaces, a gentleman asked, (paraphrasing) “Why would you prefer SOAP over z39.50?”. It’s a great question, and my answer consisted of two parts. First, I said z39.50 is not robust enough and second, I said that the development time required to recreate an OPAC with a z39.50 back-end was beyond the scope of our project.

Well, both those answers are true, but I’d like to elaborate.

First, let me provide some detail about using php with z39.50. There is a PECL extension called PHP/YAZ that is very nice, but after spending a few hours using it with our catalog, several limitations emerged.

First, The debugging capabilities are very frustrating. You can actually extract debugging info like so:

$error = yaz_error($id[$i]);

But often times, the error returned is painfully ambiguous, making a simple debug process needlessly frustrating.

Second, yaz returns all it’s results as arrays, which is great if you are doing something simple like title or publisher queries. There’s no advanced data-access that you’d really want (and expect) if you were implementing a full-blown catalog functionality with the hooks we want for external features. Take a look at this example from

Consider this GRS-1 record:

(4,52)Robert M. Pirsig
            (2,7)Transworld Publishers, ltd.

If this record is present at position (yes, access to the data is positional.) $p, then

$ar = yaz_record($id, $p, "array");

will output:

    [0] => Array
            [0] => (4,52)
            [1] => Robert M. Pirsig
    [1] => Array
            [0] => (4,70)
    [2] => Array
            [0] => (4,70)(4,90)
    [3] => Array
            [0] => (4,70)(4,90)(2,7)
            [1] => Transworld Publishers, ltd.

I’ll admit, it’s a nice tool to have on the shelf, I’m not knocking it, but it doesn’t approach the requirements we have. With SOAP, you have the luxury of defining complex data objects (then describing them with WSDL).

Third, Z39.50 cannot perform any of the patron-oriented functions we provide now (or want to in the future): checkout lists, holds, fine payment, reading histories. SOAP can provide the conduit for any of it.

Fourth, SOAP is a W3C standard. That’s right, it’s a WEB standard, z39.50 is not. When we provide web-based services, we should be using the appropriate tool, not a standard that is decades old.

The question was a good one because it puts two competing (in this case) standards on the table. I did say we should be adopting standards, but we need to make sure we’re adopting the RIGHT standards for the job at hand. I’m advocating SOAP because it is the tool we need to be using and I don’t see anything better. SOAP is complex and imperfect, but it’s robust, fast and flexible.
If we (someone) put together a set of standards by which ILSs made SOAP web services available and also how they are consumed, we’d be well on our way to a sane environment where vendors don’t have to waste time on boo-boo interface (or could just provide a vanilla interface). They could concentrate their efforts on the back end while libraries developed (and SHARED) tool-kits and UI frameworks that function cross-platform.

Oh yah, and Java could die a slow and painful death… Ahh, Utopia… Time to wake up and smell the patents.

Anyway, I don’t think I really got all this across to the person who asked me that question and it’s been bugging me.

About this entry