Marc,

Sorry that we didn't get more of a chance to discuss this last week, but
I think such a discussion would be profitable having had a chance to read
over the documents that you distributed.

"The working group evaluated the SRW and XCQL efforts but felt they were
not sufficient for addressing the needs of Elsevier.  The main issue was
the lack of a conceptual XML schema representing the searchable content
and the ability to utilize XPath expressions to query this content based
on the schema (the sort feature for SRW does support XPath expressions).
The focus of SRW appears to be on defining a common XML syntax for search
queries (really a next generation z39.50)."

The SRW group (if I can make such a generalisation) is of the opinion that
XQuery is not appropriate for searching in an environment where the client
is not aware of the details of the database.

The ability to search by XPath is very powerful, but it is also very
limiting.  Using [X]CQL, it is always possible to issue a search with
known semantics, even against databases that are unknown as the query
language defines the semantics.  On the other hand, XPath does not define
any semantics for the data, just a means of expressing a pointer to the
data.  This means that unless the world can agree on one XML schema to
use (cough), search systems will always need to map the semantics of their
data to multiple schemas and many many paths within those schemas.

Especially in a metasearch environment, this is simply not going to be
feasable.

There are some possible ways forwards on this:

1)  If you can identify the areas of CQL/SRW which you found to be
lacking, they can be addressed.  The SRW group is very committed to
working with the NISO Metasearch taskgroups to create a consistent
environment where content providers feel that the searches being performed
aren't being reduced down to a worthlessly generic level. Obviously this
is the preferred solution as it benefits everyone :)
It might very well be the case that the differences in CQL and SRW between
writing the document (I see the date is 2003) and version 1.1 have
obviated any issues that you had with the 1.0 versions.  Having looked
over specification, I believe that relation modifiers will be the answer
to many of your issues.

2)  CQL 1.1 is much more capable with respect to extension and
localization.  It would be perfectly feasable to define XPaths as access
points within a context set.
  For example:  "xpath./ead/eadheader/titlestmt/titleproper" any "fish"
But I would think of this as the last resort, as it's not very
interoperable in terms of generating queries.

3)  Even if CQL is rejected, XQueryX could be sent in a known extension to
SRW's searchRetrieveRequest.  Again, this introduces even more
interoperability issues, but is at least better than requiring
metasearchers implement a completely different framework.

Hope this helps, and thanks once again for your generosity on Thursday
night :)

Rob

--
      ,'/:.          Dr Robert Sanderson ([log in to unmask])
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Nebmedes:  http://nebmedes.o-r-g.org:8000/
____/:::::::::::::.
I L L U M I N A T I