Thanks for your replies, and sorry for taking so long, I've been out of
office for a while.
> It's not necessary, but if we don't define what happens when the client
> sends ^ in a word list, there'll be interoperability problems as
> developers make up their own minds as to what it might mean.
It is only necessary to define what it means *if* it should mean
something. If left-anchored words in word lists were not allowed, it
would not mean anything special ("^cat" would match the actual string
"^cat"). Left anchored search for normal strings could be performed
using a modifier instead:
dc.title equals/anchor=left "cat"
> Yes. Where was that example, because it's out of date.
It's at http://www.loc.gov/z3950/agency/zing/cql/, the faulty example is
at http://www.loc.gov/z3950/agency/zing/cql/context-sets/cql.html
> I agree, but would like to highlight 'not widely used'. The toolkits that
> SRW relies on are pretty widespread and available for free in many
> different languages.
That's why I have much higher hopes for SRU/SRW! Though I would like to
see some official parser files (e.g for JavaCC). I'll gladly contribute
mine when the server is implemented.
> > "A B C" --> [A, B, C]
> > "\"A B\" C" --> ["A B", C]
>
> In CQL?
Yes!
> This one really is necessary.
You are right.
> > * the "relevant" term funtion
> > How can the term function order the result set? What happens if two
> > terms have the "relevant" term function?
>
> Then the relevancies are merged, and the resultset re-sorted.
Doesn't that imply that how "relevant" a record is has to do with the
record only, and not the query? For example I would assume that the
query "dc.author any/relevant Strindberg" would rank titles with
Strindberg as main author higher than ones with him as illustrator. The
query "anywhere any/relevant Strindberg" would probably sort records
completely different. The relevancies of the first result set does not
necessarily mean the same thing when compared to the ones in the second
result set.
I would like to see ordering in the CQL though, instead of SortKeys.
Something like "title = cat order by author".
> > * XCQL
> > Why, oh why is this necessery? If it's only used for debugging, then put
> > it somewhere else, like in the diagnostics.
>
> It's only used in echoedResponse now (and debugging)
Yes, but it forces everyone to implement it.
> Prefixes are useful in the following situation:
>
> You have a gateway which sends the same query out to multiple servers,
> which may or may not use the same default names for context sets.
>
> In this way, you can name the context set maps yourself to ensure that dc
> is dublin core, not the dark custard context set.
> The counter position to this is that this is the job of profiles, and is
> in the Explain record anyway.
> The counter-counter argument was that the explain record may conceivably
> change between when you retrieve it and when you use the information in
> it (as there are no persistent connections)
But what is the probability of this actually happening? Everyone is
forced to implement it, the CQL looks hideous, for the chance that
someone changes the meaning of a prefix at the same time that someone
uses a cached explain-record. I'd say that his is definitely the
responsibility of the client.
/M
|