Hello all,

[implied modifier behaviour]
>> 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".
>I have since come around from this delusion. Mike's answer is correct
:)
Okay then.. Some confusion on my part is still there:

> =/cql.word   is adjacency
> =/cql.string is exact
> operator exact (without modifiers) and =/cql.string are synonyms.
> A cql.string is an opaque set of characters that the server should not
try to interpret.
Then, is there any difference between

a. idx = term1, and
b. idx =/cql.string term1
where term1 only contains 1 word

and

a. idx = term2, and
b. idx =/cql.word term2
where term2 contains multiple words.

If I understand everything correctly now, there should be no distinction
whatsoever - am I right?

To rephrase the above:
>A cql.string is an opaque set of characters that the server should not
try to interpret.
-> does this *only* refer to word separation, and nothing else?

The context set currently defines five 'data types' (word, string,
number, isoDate, uri). Should
all terms be assigned exactly one of those? Is there a distinction
between terms that are *not* assigned any type (either in the search
query or by the server), and terms that are typed 'string' (except for
multi-word '=' searches without any modifiers?)

[sorting]
>>> Too bad there isn't a separate spec for sorting on context set
indexes.
>> That way, Z39.50 lies :-)
You mean SRW being Z39.50 all over - something like a bulky, difficult
to implement protocol?

> To expand upon Mike's typical one-liner, the problem is that then you
have to include the entire search clause 
What do you mean by that? I hardly know anything 'bout Z39.50, maybe
that doesn't help here..

> (or attribute combination for Z) and the only thing that you can
search by are indexes, rather than relatively arbitrary data.
> I'm not (personally) averse to reworking the sort definition for 1.2,
so if you have any concrete ideas, put them forwards :)
The only thing that comes to my mind right now is starting the sortXPath
with an escaping character (preferably an XPath-illegal char, making the
distinction clear) and then follow with an index name.

[adding cql.unmasked 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!
I knew that, just testing you ;-)

[SRU testing XSLs]
>> 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? I would actually like to find these
XSLTs.  Where did you get them?
I retrieved a ZIP from the OCLC website (don't know the location
anymore) with a lot of JAR and Java files, and some XSLs in the basedir.
See the attachment for my updated XSLs.

Best regards,

Hedzer Westra, Systems Developer

Adlib | Information Systems
Reactorweg 291
3542 AD Utrecht
Postbus 1436
3600 BK Maarssen
tel: +31-30-241 1885
www: http://www.adlibsoft.com