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, Theo >>> [log in to unmask] 06/21 4:50 >>> I think you both rather miss the point. The service being accessed is the 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 do is pass along instructions and let the target system do its best with them. After all no search protocol tells a SE how to construct indexes and what 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 this 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 to search in more than one place - not specify how the world's semantics are organised. There are, as I have said before, a number of rather sophisticated - but not perfect - systems out there which handle this problem. Unfortunately, if SRU/W cannot find an extension to handle this it will become a non starter for client -> MSE communications (at least in a standard non-extended form) and an opportunity to introduce some sanity into this growing area will be lost. I will not be at the ZING meeting in Chicago (but will be at ALA), but I really would like it if this topic can be discussed and some ideas we could use come out of it. Peter > -----Original Message----- > From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]]On Behalf Of > 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 hoc > 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 a > messy crock and we shouldn't go there. > > Ralph > >