OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate forms processing


Title: RE: [search-ws] queryn: A proposal for SRU to facilitate forms processing

Hi Matthew:

> To me the queryType parameter instructs the SRU server which parser it should use to read the incoming query.

I would agree with that to the extent that the query string is read from the "query" parameter. From Sect. 5:

    "The request parameter queryType is a string indicating the query language supplied in the parameter 'query'"

What I proposed was a *prerocessing* step an SRU server could take to *assemble* the query string into the parameter "query" so that it could be read by the parser indicated by queryType ("cql" by default).

So, according to the current spec the proposal is covered by "queryType=cql" allowing that a reassmbly mechanism required by presence of "queryn" parameter has been activated.

It could be argued that there might be countless preprocessing steps, but this I believe - assembly from web form input - occupies a special position in that it is intimately bound to current web technologies for user input.

Tony

   



-----Original Message-----
From: Matthew Dovey [mailto:m.dovey@jisc.ac.uk]
Sent: Tue 12/14/2010 9:55 AM
To: Hammond, Tony; Ray Denenberg, Library of Congress; LeVan,Ralph; OASIS SWS TC
Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate forms processing

> but am less convinced about your point b) which has to do
> with presentation. In my opinion presentation (or wire encoding) is purely an
> SRU function and has nothing to do with CQL. SRU is the protocol whose job
> is to get the query across. Whether the query travels wholesale through a
> single "query" parameter or is split up over mutiple querylets (can I use that
> word? :) as signalled by a "queryn" parameter does not affect the query
> itself.

Semantically the query is unchanged, syntactically it is.

In the same way in classical propositional logic we have the "standard" notation (e.g. a ^ b) but some use Lukasiewicz's notation (e.g. Kab). Whilst both notations express the same query, I would regard these as different queryTypes.

Similarly, if for some reason, I decided to write a variant of CQL which used polish (or reverse polish) notation instead of infix, that would be a different queryType.

I think, there may be a nomenclature problem, as I agree that these are the same type of query, but not the same queryType! To me the queryType parameter instructs the SRU server which parser it should use to read the incoming query. The SRU server will require a different parser depending on whether the CQL is encoded in the normal format, your form-based encoding or my mythical polish variant.

Matthew

********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]