> There's a little bit of history here (even for such a reletively young
> standard!) - some of us wanted an XML based query language so that we
> could use XML tools to build and deconstruct the queries; others wanted
> a string based query language (which fits better into URLs but requires
> Lex/Yacc type approaches to deconstruct etc.). I favoured the XML side,
> but the string people won in the end - in SRW you had to support both in
> the request, now XCQL is relegated to just echoed requests in the
> response.
Yes, this struggle is evident in the CQL.

> One of the reasons behind the SRU variant is to allow thin (also know as
> dumb or brain-dead) clients.
Well, search+retrieve should be a no-brainer, at least on the client
side. Though I think SRU has potential as a machine-to-machine protocol.
Keeping 3rd party toolkits (Axis, MS SOAP toolkit ...) to a minimum is a
Good Thing.

> These would just use XSLT to generate the
> entire user interface on the fly (e.g. making us of Internet Explorer's
> inbuilt support for XML and XSLT). The problem here is that XSLT is not
> particularly good at deconstructing strings, so the XCQL form for
> responding back is needed is the XSLT base user interface is going to do
> anything clever in terms of allowing the user to refine their query etc.
It could still be optional though.

/M