 |
 |
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