> Date: Thu, 9 Dec 2004 18:22:44 +0100
> From: Hedzer Westra <[log in to unmask]>
>>> 2. exact searching w.r.t. pattern matching (which would imply that
>>> cql.masked and cql.string are mutually exclusive)
>> I believe so. exact is treated as anchored at both ends, and may not
>> have any masking characters.
>> =/cql.word is adjacency.
>> =/cql.string is exact.
>> No, a masked string is just fine. (Why would we prohibit such a
>> useful thing?)
>> dc.title exact "the adventures of *"
>> will find
>> The Adventures of Hulk
>> The Adventures of Baron Munchausen
>> The Adventures of the Famous Five
>> but _not_
>> The Amazing Adventures of Captain Gladys Stoatpamphlet and her
>> Intrepid Spaniel Stig.
>> because the extra word "amazing" breaks the "exact" condition.
> Hmm, this is something different. I'm up for Rob's description if
> nobody minds. This is coincidentally the way I've implemented it
> already :-)
Note that Rob's interpretation and mine are identical _except_ that
Rob believes there is an arbitrary prohibition on the use of
wildcarding when the relation is "exact". Since there is only one
possible interpretation of this combination, I argue that servers
should be free to implement it (though also, of course, free to reject
such queries with an "I don't support that" diagnostic).
>>> But then you'd also need to be able to specify cql.unmasked or
>>> something to disable pattern matching.
>>Yes; there should be a cql.unmasked relation modifier.
>> You can escape the pattern characters, or define a new modifier
>> that overrides the masking -- for example you might want foo.regexp
>> as a different set of masking rules.
> If I understand it correctly Mike suggests to extend the CQL context
> set, and Rob suggests to define it in our own context set.
The substance of our answers is in agreement: it is established that
relation modifiers can be used to override default masking rules. The
only question is whether an "nonmasked" relation modifier should be
added to the CQL context set. Since adding this is backwards
compatible, I see no reason not to do so.
> Let's have the SRW 1.2 people decide upon this!
We _are_ the SRW 1.2 people!
>>>> - why is sorting defined on XPaths?
> Too bad there isn't a separate spec for sorting on context set
That way, Z39.50 lies :-)
>> [Marc] recommended the fine YAZ command-line client ("yaz-client")
>> for SRW, and the web-browser of your choice, or wget, for SRU.
> Very good! I guess his e-mail got lost in my spam filter, I
> retrieved the msg from the archive and got CQLJava which contained a
> set of XSLs which turn IE into a SRU browser.
CQL-Java contains that? Really?
$ cd /usr/local/src/z39.50/cql-java/
$ find . -iname '*.xsl*' -print
I would actually like to find these XSLTs. Where did you get them?
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ Overweaning, participle vb. -- force-feeding a baby with
pieces of steak.
Listen to free demos of soundtrack music for film, TV and radio