On Mon, Jun 17, 2002 at 10:21:00PM +0100, Matthew Dovey wrote:
> > > 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,
> > manipulate
> > > 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
But we are talking about SRW and SRU. SRU wants a simple textual
query language. I don't think SRU people are going to be happy
having to generate a URL query parameter that is an XML encoded value.
Moving to an XML encoding of queries is a radical change away from
where I thought SRU/SRW started from. Its more in the XER line
of things. I also personally believe it will raise the acceptance
barrier. People are used to things like SQL. Programmers don't write
applications using SQL by creating a tree of data structures. They
write a textual query. The length of client code can increase significantly
when you have to build up data structures node by node etc to form
a query tree.
So I am afraid I disagree with Matthew on this one. I think SRU/SRW
should have a small simple API. I think it was Theo who was in favor
of having the same power in SRU and SRW requests - by defining all
requests as having a simple list of (possibly optional) arguments
effectively of type string (I am paraphrasing here). This is all
you get with SRU. And a goal was to *try* and keep SRW not that
dis-similar to SRU.
If you want to go for an XML query language, I think that is fine,
but define it as a separate service. I think its against the grain