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: Substitution Parameters in CQL


Title: RE: Substitution Parameters in CQL

Hi Matthew:

Interesting idea but doesn't this suffer from the same defect that my initial idea of arbitrary string fragmentation [1] had, namely that empty values will upset the querystring and render it non-CQL.

And if we bring JavaScript into the picture then a) we don't need the template as such, and b) we still haven't resolved connecting *any* form (with multiple inputs) to an SRU server (expecting one query input) because we have an N:1 impedance mismatch on query parameters.

We should note that JavaScript is a client facility over which the user may or may not have control.

Tony

[1] My initial idea was to break a query string into consecutive numbered fragments which could then be recomposed by sequencing the fragments, i.e.

    query = q1 + q2 + q3 + ...


-----Original Message-----
From: Matthew Dovey [mailto:m.dovey@jisc.ac.uk]
Sent: Thu 12/23/2010 9:13 PM
To: Hammond, Tony; 'Denenberg, Ray'; 'OASIS SWS TC'
Subject: Substitution Parameters in CQL

I felt that there was a nore elegant solution to the forms issue, and I've realised what I'd been vaguely thinking of - allowing substitution parameters in CQL.


Basicallly, the idea is that you can put a placeholder in the CQL query itself whose value is take from a url parameter.

I'm going to use {} to indicate these parameters in my examples, but we may need a better syntax to avoid ambiguity.

So the query

author = {qt1}

would be interpreted as author = whatever the value of the qt1 parameter is.

A form with two input boxes allowing an author and title search would have a hidden field for the query parameter with the value

author = {qt1} and title = {qt2}

A more generic query would be

{qi1} {qr1} {qt1} {qb1} {qi2} {qr2} {qt2}

I have used Tony's convention above but there is no particular need to. I could use

author = {author} and title = {title}

This would clearly only work for forms with a fixed know number of search terms. However since in order to have a form which allowed the user to arbitrarily add search terms would require javascript anyway, this isn't an issue.

The idea needs work to turn this into a robust specification (either a new CQL feature or an extension to CQL) but I wanted feedback as to the approach.

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]