At 10:45 14-11-2002 -0500, LeVan,Ralph wrote:
>How about a compromise that can be obsoleted by the next release?
Woa! You're scared by the consequences of our syntactic change and now
we're negotiating profiles? :-) That seems like a pretty big step to me.
>Stick a section in the Explain record that lists the Profiles supported.
>(We should probably have that in ZeeRex as well.) This then lists the
>behavioral rules that apply for this database. (And that's why it's not in
>ZeeRex. When you support diffent databases, you can't promise that you
>support the profile in all the databases.) The profile can mandate the
I don't see the point of the paranthesised comments. ZeeRex is a database
description format, not (primarily) a server-description format. I presumed
the reason it's not been done before was that it was potentially thorny and
something that had never been thought through.
>I'm am moved by Sebastian's observation on the redundancy of registering two
>things in a profile: the URI and it's prefix. I'd be happy to hear a
>suggestion that fixed this and still left SRU simple.
The only hard fix I see, frankly, is a registry of prefixes, but I also
have to say I really would rather not have that. I think Rob's (tongue in
cheek?) request to register 'archive' says everything about why that is bad.
But there is a soft fix which I still think gets us all the way there. The
Manchester crowd has proposed that we have the *option* to stick URIs for
index sets into the query (like we do in the Type-1 query, essentially).
You don't have to do it. You can rely on a priori agreements, profiles, or
Explain inforations to keep the queries short for SRU. BUT those of us who
might wish to do cross-searching without relying on cached URI/identifier
maps can stick those URIs in the query the old-fashioned way and be done
with it. It's not significantly harder for the server, but it's potentially
a lot easier and more reliable for the client developers.
Maybe the recursive grammar suggested for the job is too geeky and should
be simplified -- I think that can be discussed... but I think it's worth
bearing in mind that the Manchester suggestion doesn't make your average
SRU query any longer.. but it does allow for a longer query which benefits
from being unambiguous when you need it.
--Sebastian
--
Sebastian Hammer, Index Data <http://www.indexdata.dk/>
Ph: +45 3341 0100, Fax: +45 3341 0101
|