I realise that I started a discussion on issues that I think are quite
fundamental and I did not realise that my objectives and requirements
(e.g. metasearch) were so different from the rest of this group. BTW, I
changed the original xPath subject.
There some thoughts on these issues on a more conceptual level that I
want to mention.
1) I expected SRU/SRW be used not only for b2b communication but also
for metasearches with users sitting at the orher side. There may be
quite different requirements from both types of usage and sometimes it
is better to combine opposite solutions than find a
compromise in the middle. For the time being I do believe that is
possible that SRU/SRW meets both types of requirements and that there
should be no need for metasearchers to develop their own protocol.
2) Coming back to the hardware store analogy. The store provides
objects and information on those objects and we have to make a
distionction between both. When a user goes to a store he doesn't always
know the right question and has to be guided by
relevant information. Asking for "type 5 nails" should NOT result in
providing "type 6 nails" as being most close to type 5. It should result
in relevant information on the objects that are close or better or
replace what has been asked for, so the user can request the rigth
objects or decide to leave the store. Our SRU/SRW protocol can do better
than just saying "No we do not have type 5 nails" and this could be an
important step into the metasearch.
3) My idea of compatibilty is not just getting the right diagnostic
saying "no I can't do that" and I also do not want the server to be
creative. I do want us as a group to be creative in specifying more well
defined optional responses so communication does not have to stop when
the client/user didn't ask the right question. Clients and servers are
quite capable of neglecting optional data they do not understand without
conflicting with a minimum level of predictability (we do not only ask
questions for which we already know the answer) and there is no need for
flags for all of these optional responses.
4) We should not use "explain" to allow for holes in the protocol. Of
course we need to have some information in advance on a target before
making it part of our lists of targets and we could use that information
to provide target-specific searches. But on the other hand it would
improve compatibility if there were some basic searches that would
always work without the need for target-specific searches for the same
(meta)search on different targets. I do not expect my searches to work
on an arbitrary list of systems, but my list of systems will not be
arbitrary, but within a certain domain. But even when I do a metasearch
for "any Mercedes" in a library catalogue and a secondhand-car database,
it does not require future technology to return something useful.
We do not have to agree on these issues when we introduce
the"creative/metasearch flag". I was not a favour of such a flag, but I
begin to realise that it is the only way to meet the extra
requirements.
Theo
|