> > > searching multiple databases has been dropped . . . if the
> > > each one has revenue and royalty related business rules associated
> > > with it and must be distinguished from the query."

> engines. They would vastly prefer a model where the metasearch engine
> (gateway) is able to bundle such requests together so they can optimize it
> adequately.

Ahha.
Yep, having now read the paper, I see the issue.  Depending on the
backend, it would be possible to do less work than (query *
databases) if you knew that the client wanted it applied to more than one.

I almost agree with their solution, but not quite.  I'd prefer something
like:

<multipleSearchRetrieveRequest>
  <singleSearchRetrieveRequest>
    <resource>/foo/</resource>
      <searchRetrieveRequest>
        <query>...
  <singleSearchRetrieveRequest>
    <resource>http://srw.o-r-g.org/l5r/</resource>
      <searchRetrieveRequest>
        <query>...

<multipleSearchRetrieveResponse>
  ...

Then we could simply put existing messages inside a wrapper, and servers
that don't need to/can't optimise will just step through the requests as
if it had received them individually.

A bit more verbose, but it doesn't use attributes and is easy to farm out.
Also, if database were a full URL as in the second instance, it would
provide a mechanism for SRW<->SRW gateways, something that I vaguely
recall Adam discussing the current impossibility of a while ago.

It also doesn't change the existing definition of searchRetrieveRequest,
it just adds another service to handle the multipleSRR element.

> > > There was also a desire for more result-set and record metadata.
> >Were any specifics given?
> Yes, the big wish was basically for more "branding", primarily in the form
> of links back to the information provider... they (perhaps justifiably)

These are per database, rather than per record?  In which case they
belong in ZeeRex, and we have scope for them already with the <link> tag.
Which I blushingly admit isn't documented on the site, but is in the DTD
for just that reason.


> their database, and they would like to see metasearch vendors provide links
> to their native interface for individual records as well as for result

So a field which allows you to point at other ways to get to the same
digital object, regardless of the schema that's requested for the display.
Sounds reasonable.

Rob

--
      ,'/:.          Rob Sanderson ([log in to unmask])
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Twin Cathedrals:  telnet: liverpool.o-r-g.org 7777
____/:::::::::::::.              WWW:  http://liverpool.o-r-g.org:8000/
I L L U M I N A T I