Eric Lease Morgan wrote:
[snip] I'm still not an expert in this regard, but I do know that
things like the query "dogs cats" (without the quote marks) is an
invalid CQL query because I think CQL is expecting phrase searches or
truples (dogs or cats). In the query "dogs cats" (without the quote
marks) dogs is considered a field, cats is considered an operator,
and there is no value field.
I'm just beginning to explore CQL with reference to an SRU
implementation I'm piecing together but I was responding to the examples at:
http://www.loc.gov/standards/sru/cql/index.html#features
which include
* title all "cat hat"
** title any "cat hat"
** title exact "cat in the hat"
The fourth
** title = "cat in the hat"
is semantically equivalent in swish so it's a no-brainer.
With you I was generally prepared to ignore them as extras. Then I
submitted the site to
http://alcme.oclc.org/srw/SRUServerTester.html
which does both "=" and "exact" searches as part of the test. When
someone else associated with the SRU project raised the "any" test, I
started giving this set of tests a little more attention.
I understand that swish doesn't support "exact" (i.e. does my search
string match the entire field?), although I would be delighted to be
corrected.
But this *is* a semantic equivalent to "all" and "any" in swish, so we
should be able to make these searches succeed.
*
[big, useful code snip] I sincerely don't know if it were better to
"fix" this problem in a person's client or in the SRU module.
* I absolutely defer to Brian's superior understanding of the code but I
rather think that the answer is to do the transformation *inside* the
package. Perhaps this is just because I'm coming to it at a higher
version number when it is possible to expect more, because some of the
earlier challenges have been worked out.
*
On the other hand, for most of the CQL query types I get the line:
croak( "Swish does not support relational modifiers" )
This handling of errors, through the use of croak, also needs to be
trapped in your code because if you don't, then non-XML gets returned
to the client, and that is no-no #1. It has been suggested to me you
trap for this error something like this:
eval { $cql->to_swish(); };
if ($@) { # do something about the error }
I'd really love to help reduce the above croak to something more
articulate. Respecting the fact that each supported toIndex() method
brings with it a different set of challenges. There are meaningful
diagnostics listed at:
http://www.loc.gov/standards/sru/diagnostics-list.html#cql
that would be particularly useful. For example, if the relation proves
to be exact, and a 19 diagnostic is returned (along with the offending
relation) I can program for that. In fact if I knew the relation was
"exact" I can send that off to the underlying database.
I'm certainly willing to attempt some of the swish specific analysis, if
it will help.
Walter
