> > No, No, No, No, No (you've stopped being sensible now Alan!).
> > Typically users shouldn't be typing in CQL. There
> should be a
> > nice easy to use interface allowing them to build queries,
> > previous sets etc.
> I just wish to place on record my fundamental disagreement
> with this stance. Or at least, I agree with it as stated,
> with the word "Typically" in front, but not when that word is
> deleted, which is what Matthew implies. For sure, some users
> will want a "friendly" (i.e. dumbed down) UI for querying.
> But in any serious application, there will be "professional"
> users who need access to the power of CQL.
Aaaaagh! - SRW is suppose to be about defining an on the wire protocol *NOT*
a user query language (IMHO). These are different endeavours (albeit
admittedly related). I suspect basing CQL on CCL is causing more confusion
I don't disagree that a UI may wish to provide an advance text string way of
entering queries - I don't think anything in my original e-mail ruled that
sort of interface out or explicitly implied the interface should be
graphical. However, the interface be it a text input, fancy graphic or
whatever should not be determined by the on-the-wire messages - otherwise
(IMHO) we have the cart pulling the horse. If I want to provide a human
typeable query langauge (be it based on CQL, RPN, PQN or whatever) then the
client needs to parse this into the on-the-wire messages (which incidently
isn't what XSLT is very good at, hence my comment it would be difficult in
the SRU case). If that query language wants human assigned/human readable
names for result sets fine - but the client is responsible for resolving
these to the server assigned result set id's when it passes over the wire.