At 05:03 PM 12/14/2004, you wrote:
>[...] if you need Very Long strings to be sent, then just use SRW
>not SRU?  Not easy to do from a web page form, granted, so there is some
>appeal to SRU.
>
>Rob

The Web Form (CGI) approach is very strongly embedded in existing apps.
I think we can predict that the majority of gateways to existing Web
search servers as well as GILS, Geospatial and Biological search will
be using use SRU rather than SRW, at least during the first couple
years of uptake. In many of these cases, HTTP GET will be sufficient,
but I do think some will need HTTP POST.

We can look at a typical Geospatial search driven by the Isite app
through a mock-up demonstrator at http://www.gils.net/sru-geo.html
Let's assume we just search for title='water' and we target the Library
of Congress. Let's assume we do not need to make explicit reference
for the CQL, REC, or DC context sets, but we do for the GILS and GEO
context sets. If you hit the "Show SRU" button, you get the following:

http://www.indexdata.dk:9000/voyager?operation=searchRetrieve&version=1.1&startRecord=1&recordSchema=dc&maximumRecords=50&query=%3Egils%3D%22http%3A//www.gils.net/context-set.html%22%3Egeo%3D%22http%3A//www.blueangeltech.com/Standards/GeoProfile/%22cql.serverChoice%20any%20%22water%22&

The SRU URL just to search title='water' is already 287 characters.
My understanding is that a URL can be up to 1024 bytes. But one
should anticipate the URL characters being sometimes sent as Unicode
(up to four bytes per character), so the safe length is really 256
characters.

There are multiple points in the SRU specification where one can
embed another URI (e.g., schema) within the SRU URL, and perhaps
in practice that's going to give longish SRU URL's pretty quick.

We may also find that some gateways will need to carry along
quite a lot of stuff with extended parameters ("x-whatever=").

I understand Matthew's point that SOAP tools like .Net assume
that the SOAP process lives at a service point that expects only
SOAP messages. I hope someone can offer a clever way to retain the
nice feature of a commonly named service point between SRW and SRU,
yet provide for an HTTP POST to be SRU as well as SRW.

Eliot