> I'm trying not to get involved in this discussion,
Please do! I only question these things to make sure we've considered
the options...
> 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.)
But do we really need a full blown eSpec or just brief and full EAD
record specs? (I have a feeling you're going to say yes ;-) ). Will we
in practice really have clients requiring arbitrarily differen "brief"
EAD summaries or will it be the case that one or two brief ones will
suffice? How many other cases would be dealing with 40MB records where
we would need arbitrarily different summary records (rather than one or
two)?
A full EAD record is almost a database in its own right, so perhaps you
want to search with a finer granularity as to the level of the record
you want back rather than do eSpec/qSpec things? And yes, I can remember
all the discussions which eventually lead to qSpec at the 98 ZIG.
>> //holdings/holding[library='mylibrary']/shelfmark
>
>Yes; any off-the-shelf XPath implementation should handler this.
Yep - that was my point, you throw in an full Xpath implementation off
the shelf rather than do a complex hand-coded lookup table and this
comes with lots of clever Xpath extensions in which you hacker manages
to exploit to get into your server...
Matthew
|