I agree that we should avoid "vague semantics", but what I try to achieve is "generic" and "flexible" rather than "vague".   
Our common concern on this list is interoperability and I think we agree on lots of aspects. But sometimes we need to take a look at the complete opposite direction than we are used to in solving interoperability problems. In my approach that is to enable "result-driven" output besides "request-driven" output, but still with exact semantics, but I certainly do not want servers just to "return what they like". 

By actually letting our SRU/SRW clients and servers talk to each other we get a better feeling for the practical implications of these discussions. The client I am using is a simple stylesheet that serves as a SRU-portal, which can be accessed via:
http://redbelly.kb.nl/coop/tel/srudbs.xml
In this XML file all SRU-targets are listed that are located at the same machine as the SRU-server to prevent IE-security problems. There is an additional XML file at:
http://redbelly.kb.nl/coop/tel/zngdbs.xml
In this file with SRU-targets are located at different machines and you should make sure that access across domains is enabled in IE.

Now what I would like to do is put all the SRU-servers in one targets list like the two above to get an impression of the differences. Up to now the only external SRU-server in the above XML taget list is Ralph's SRU-server. 
So a request to everyone: send me the base-url of your SRU-server and I put them together in one portal.


Theo


>>> [log in to unmask] 23-05-02 04:10 >>>
On Wed, May 22, 2002 at 11:36:10AM +0200, Theo van Veen wrote:
> Let me put it completely differently.
>
> First - correct my when I'm wrong

I think you meant "me" not "my" :-) :-) :-)  Sorry, coult not resist.

> - the use of a Bath profile was in my opinion to get clients and
> servers  supporting the same queries to establish interoperability. In
> my personal view the need for such a profile  comes from the lack of
> Z39.50 to deal with differences in general between servers and/or
> clients. With SRU/SRW we now have an opprtunity to get this right

Agreed.

> Second. In the SRU/SRW discussions Z39.50 and what SOAP toolkits can
> or cannot do play a role. In my personal view this shouldn't be the
> case.

I can see your goal, but I don't share it exactly. I think SRW is under
the ZiNG umbrella - the 'Z' being Z39.50. I am interested in SRW
cleaning up SRW, make things more standard, but for use with Z39.50 so
what Z39.50 can and cannot do is important.

What do other's on this list feel?

> The answer is quite simple: The server decides whether it can handle
> the query and if not....

Because of the Z39.50 slant, I have no objections to such goals, if I
can work out how to make it work with Z39.50. I agree with the goal of
getting SRW nice and consistent. What I would like to do is to be able
to provide a configuration file to a SRW gateway product which generated
the correct Z39.50 attribute lists for a particular server to answer
the query. So if different Z39.50 servers have addressed something in
different ways, fine - as long as I can write a new configuration file
for that particular server.

My fear is I don't think SRW will take off if it requires each vendor
to implement SRW. It just takes to long. I would like to be able to
generate a SRW product that can be used in front of any vendor's Z39.50
database - using configuration files to adapt it in a suitable way for
that target.

> The minimum what a server can do is say "no hits I do not support
> this query". A "better" server would say "no hits I do not support this
> query ...
> My proposal sounds silly and  illustrates the big gap between my
> preferred approach and other approaches but I just give it a try as
> there might be people that also like this approach.

I don't think you proposals are silly at all. There are good aspects
to them. I am happy to argue through details. But *I* will keep bringing
Z39.50 into the discussion because of my *personal* objectives.

Also, I don't like leaving things vague (maybe my background). So I
dislike a spec saying "an implementation can choose what 'supports'
means, and what 'better' is." I would rather concrete statements such
as: "if an index name is specified that is not known by the SRW gateway,
it will look for another name with different prefixes. If it finds
multiple matches, it will OR them together. If it finds no matches,
it will ignore the search term." I am not proposing this as a rule,
I just want concrete rules defined. Without agreement on how to interpret
a query, I think interoperability will go down and you will end up with
the Z39.50 vague semantics (in areas) all over again. I want to avoid this,
so I want precise specifications, not implementation choices.

So I have no objections to you bringing up goals. I think it is good.
But I want details so I can work out how to implement it. I want
consistency in implementations for interoperability, so I want the spec
to specify exact semantics and what to do in different circumstances,
since SRW is (in my opinion) intended for use with Z39.50. I am happy
to provide an additional level of better semantics on top of Z39.50
to clean things up a bit, but I want a mapping from those semantics
to Z39.50 semantics.

As I say, others are free to disagree!

Alan