> Date: Fri, 18 Jul 2003 16:54:26 +0100
> From: "Matthew J. Dovey" <[log in to unmask]>
>
> I can't help thinking that eSpec is a throw back to the days when we
> had very slow communication speeds. Whilst I can think of
> hyperthetical situations in which this may apply in most cases
> transfering the additional data over the network is not such an
> overhead.

I'm trying not to get involved in this discussion, but I have to poke
my nose in here and say that I don't buy this argument.  If we're
talking about XPath'ing an element out of a 400-byte DC record, then,
OK, you may as well send the whole thing to the client and have it
done there; but people will also use SRW to fetch summary records from
40Mb EAD records.  I think an eSpec-alike is indispensible for
building a Real IR protocol (as opposed to something for people to do
web-searches with.)

> For eSpec we could use a similar subset. However, I think that many
> would start asking about qSpec too; the typical example for library
> holdings data being something of the form
>
> //holdings/holding[library='mylibrary']/shelfmark

Yes; any off-the-shelf XPath implementation should handler this.

 _/|_    _______________________________________________________________
/o ) \/  Mike Taylor  <[log in to unmask]>  http://www.miketaylor.org.uk
)_v__/\  "Have you killed anyone?" / "Yes, but they were all bad" --
         Arnold Schwartzenegger, "True Lies".

--
Listen to my wife's new CD of kids' music, _Child's Play_, at
        http://www.pipedreaming.org.uk/childsplay/