Let me put it completely differently.
First - correct my when I'm wrong - 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
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. It is the implementors responsibility to map SRW against existing Z39.50 implementations, but existing Z39.50 implementations should not influence (better) choices for SRW/SRU. In the "new situation" in which SRU/SRW is an accepted potocol there is no need to have a Z39.50 step between SRW/SRU and the server, because SRU/SRW use the native interface to newly developed servers.
Now I come to my prefered approach.
I have a CQL query that is the function f(a,b, ...) on a number of terms. This function may be boolean with proximity etc. Each term is a function g(x) on a single string x. This may be a phrase or a word with truncation and wildcards and other operators to indicate some attributes including the index name. The index name is generally (not always) only related to field in the originating record and does not specify how the field is indexed (although in somes cases it is trivial how a field is indexed). Now there can be an inifinite number of combinations and of course not all servers support all combinations.
The question is how to deal with the differences in implementations in such a way that it does have a minimal effect on interoperability. Getting error messages is something I consider the result of a lack of interoperability.
The answer is quite simple: The server decides whether it can handle the query and if not, it provides a response with additional information, that can be used by the client e.g. to improve the query. If we are able in SRU/SRW to come up with a good proposal for how such a response should look like then we can increase interoperability without the need profiles while leaving a lot of flexibilty and freedom at the server.
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 but the query that comes most close to what you want is: 'new_query'". A client that is even more friendly will say I do not support your query but here are the results of the a query that I do support and which will most likely be good enough.
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.
Theo
>>> [log in to unmask] 22-05-02 03:41 >>>
On Tue, May 21, 2002 at 12:39:49PM +0200, Theo van Veen wrote:
> I am still confused.
> - I remember discussions on the use of quotes but I do not remember
> decisions to move CQL towards CCL.
I cannot remember if a "decision" was officially reached or not (to me,
Ray's web pages are the master copy), but I think it was Ralph that
suggested it and I certainly agreed with the idea of "if we have
exactly the same semantics as CCL, and the CCL syntax is fine, why
not use the CCL syntax instead." If there is a good reason not to
use the CCL syntax, I agree completely we should use a different syntax.
> - In CCL I think we have the same problems with respect to word like
> "and" and "or".
Yes, absolutely. Ignoring CCL, my point was if "and" and "or" are
reserved words in CQL, then they need to be released somehow. Using
quotes seems a logical solution. Feel free to propose other semantics
for what different punctuation should mean in a CQL query. In fact
I would encourage it! It saves time however if the proposal can be
fairly encompassing. For example 'double-quotes should mean string-attribute'
is not enough. Are "and" and "or" reserved words? If so, how to release
the meaning of reserved words? If its also to use double-quotes, then
I dislike it because it means I can only search for "and" with the
string-attribute specified. (I am using this just as an example.)
> We have the opportunity to make a nice clean start with CQL. Let's
> make use of that. I think that "making things different from CCL" is
> not an issue or an argument in itself, but when we try combine the best
> of all worlds in CQL, there might be arguments to use things from CCL.
I agree completely. I don't want to take CCL verbatim. But if there
are good bits, I agree with Ralph (I think it was Ralph!!) who said
'why not steal CCL syntax where appropriate rather than argue over
whether ':' or '~' or '-' is better to separate the index name from
the term'. I agree with this. Most of the CCL syntax is not horrible,
so to reduce time arguing over which punctuation symbol to use, I am
in favor of stealing syntax from CCL when we like the semantics.
Its also more famililar to people (YAZ has something, OCLC has something,
Z39.58 was noised around a bit, ISO8777 is (was?) a standard, we support
it, etc).
But I agree 100% if we need to do something that CCL does not do, or
if CCL does not do it the way we want, then we don't use that bit of CCL.
> I had hoped on a generic approach with standard index names and
> operations (like truncation, completeness etc.) where all the
> "attribute" variants can be constructed in a logical way instead of
> agreeing on names for each individual "attribute" variant. I favour the
> approach in which the server tries to find the best match between how a
> field is indexed and what variant is asked for.
If you have have a concrete proposal, please make it! Your intensions
sound good, but I have no idea how to implement it. I want a concrete
computer algorithm to turn a CQL query into a RPN query with attribute
lists for sending to a Z39.50 target. If you want a proposal where the
CQL->RPN convertion uses 'best match' rules, then can you please propose
a formal model of the data structures the convertion process needs
and the algorithms for converting a CQL input string into a RPN query
with Z39.50 attribute lists etc using that formal model. Without concrete
proposals we are not going to get anywhere.
I am completely against any proposal that says 'here is the legal
syntax of CQL - a CQL->RPN converter should do whatever is best
to satisfy the users need, where the best way to achive this is up
to the implementor'. Any thing left to a specific implementation is
(in my view) completely counter-productive to any standardisation effort.
Alan
--
Alan Kent (mailto:[log in to unmask], http://www.mds.rmit.edu.au/~ajk/)
Project: TeraText Technical Director, InQuirion Pty Ltd (www.inquirion.com)
Postal: Multimedia Database Systems, RMIT, GPO Box 2476V, Melbourne 3001.
Where: RMIT MDS, Bld 91, Level 3, 110 Victoria St, Carlton 3053, VIC Australia.
Phone: +61 3 9925 4114 Reception: +61 3 9925 4099 Fax: +61 3 9925 4098
|