[Matthew]At the moment the intent is that the same URL is used for both
the SRU endpoint and the SRW endpoint.
[Mike](Aside: is that intent documented anywhere?)
Well, the ZeeRex record contains the following info:
<serverInfo protocol="SRU" version="1.1" transport="http">
Since serverInfo is non-repeatable (if my understanding of DTD is
up-to-date) there is no way to supply more than one
[Hedzer] What reasons are there for not allowing it, then? I'm all for
[Hedzer] allowing it (mostly because of the GET length problem).
[Matthew]The server has to be able to determine whether it is getting an
SRU request or an SRW request, and at
[Matthew]present the server can distinguish that by whether it gets a
HTTP GET (hence SRU) or HTTP POST (hence [Matthew]SRW).
[Matthew] Allowing a HTTP POST to be either SRW (i.e. SOAP) or an SRU
based POST (or potentially a more REST like
[Matthew]POST with the SearchRetrieveRequest cast in XML but not within
a SOAP envelope) would
[Matthew]A) require some fiddly logic at the server end which would
often mean hacking the SOAP toolkits to do
That's just a technicality..
[Matthew]B) potentially break existing implementations
[Mike]But there are other ways. The YAZ implementation of SRW allows the
same port to be used for both
[Mike]SRW and Z39.50 -- we just peek ahead at the first few bytes of the
request and switch on what we see there.
[Mike]They same could certainly be done, pretty trivially, for determing
whether a POST payload is SRW or SRU.
I agree. Not being able to program POST content-type checking for
certain implementations should not mean that the SRW/SRU protocol should
And I'm all for *not* dropping SOAP, just because not many people
implement it now. Who knows how many well optimized SOAP toolkits will
emerge in the future?
[Mike]What we're proposing here is a really, really simple fix which
doesn't seem to have any downside
[Mike](theoretically at least): we let SRU client implementors change
[Mike] <form method="GET">
[Mike] <form method="POST">
[Mike]when their URLs get too long.
Hmm, that's just a simple client-side fix. But the client should be able
to find out whether the server actually supports it..
I propose to extend ZeeRex:
- make serverInfo repeatable
- add an attribute @method to <serverInfo>
<serverInfo protocol="SRU" version="1.1" transport="http"
<serverInfo protocol="SRW" version="1.1" transport="http" method="post">
This configures SRU on gondolin.hist.liv.ac.uk:80, POST and GET
and SRW on gondolin.hist.liv.ac.uk:8080, POST
<serverInfo protocol="SRW/U" version="1.1" transport="http"
This configures SRU and SRW on gondolin.hist.liv.ac.uk:80, POST and GET.
(Although GET probably bites with SOAP, so maybe this is a bad example.)
Question: does protocol="SRW" need extra attributes like RPC or
doc/literal ?? I don't know enough about SOAP for that..
Hedzer Westra, Systems Developer
Adlib | Information Systems
3542 AD Utrecht
3600 BK Maarssen
tel: +31-30-241 1885