Perhaps it makes sense to have a list of "unregistered" or "unapproved"
extensions on the same page that lists the registered extensions.
Whatever is being decided on multiple databases its just a fact that
such an extension is being used locally by some of us. Just explaining
on that page how someone is using a local extension might help to
prevent divergence.  We (European Library) use x-collection for
specifying a specific collection and x-base (KB) for specifying a
base-query which can be anything and is used as an escape to create
virtual collections.
I agree with Peter that the lack of such an extension can be a
showstopper and I agree with Ralph and and Rob that too much complexity
can be a showstopper as well. Therefore we need to find the right
balance between specifying what is part of the standard and publishing
what is being used by individual implementors.

Have a good meeting,

>>> [log in to unmask] 06/21 4:50  >>>
I think you both rather miss the point. The service being accessed is
MetaSearch Engine - not the databases it will access. It is the
province of
the MSE to determine all of this "messy crock". All the protocol has to
is pass along instructions and let the target system do its best with
After all no search protocol tells a SE how to construct indexes and
algorithms to use when assigning documents to subject clusters or any
of the
other things SEs do for a living. SRU/W should not try to undertake
level of complexity - I agree, and I was not asking for it.

All I would like to see is SRU/W make provision for a simple request
search in more than one place - not specify how the world's semantics
organised. There are, as I have said before, a number of rather
sophisticated - but not perfect - systems out there which handle this

Unfortunately, if SRU/W cannot find an extension to handle this it
become a non starter for client -> MSE communications (at least in a
standard non-extended form) and an opportunity to introduce some sanity
this growing area will be lost.

I will not be at the ZING meeting in Chicago (but will be at ALA), but
really would like it if this topic can be discussed and some ideas we
use come out of it.


> -----Original Message-----
> From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]]On Behalf
> LeVan,Ralph
> Sent: Monday, June 20, 2005 9:58 PM
> To: [log in to unmask]
> Subject: Re: Betr.: Re: Multiple Sources in SRU/W
> > -----Original Message-----
> > From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]]
> > On Behalf Of Dr Robert Sanderson
> >
> > I disagree.  The amount of complexity in Z39.50 for searching
> > multiple databases at once was a serious impediment to
> > implementation, and the same will apply to SRW.
> I absolutely agree!!
> What sort of explain record are you going to generate for this ad
> amalgam database?  How are you going to explain that records from
> database A are available as MARC and B's are available as DC?  It's
> messy crock and we shouldn't go there.
> Ralph