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] RE: cql-form issues checklist


Title: RE: [search-ws] RE: cql-form issues checklist

I fully agree with Matthew. Alternate query strings were meant to sit within the query parameter, and queryType was meant to invoke an alter query processor.

In fact the notion of additional queryType parameters only arose because we were considering how to deal with a distributed *CQL* query. In essence the same type of query, albeit scattered here, there and everywhere. But in view of the need for preprocessing to assemble the query, and also (as Matthew earlier pointed out) that we were dealing with a subset of CQL then it was deemed better that we treat this as a new query type.

But we hadn't got to the point of considering non-CQL queries with their own dedicated parameter sets, although the new views on queryType might seem to encourage that.

Tony


-----Original Message-----
From: Matthew Dovey [mailto:m.dovey@jisc.ac.uk]
Sent: Thu 12/23/2010 9:39 AM
To: LeVan,Ralph; Hammond, Tony; Denenberg, Ray; OASIS SWS TC
Subject: RE: [search-ws] RE: cql-form issues checklist

>The query parameter is defined by the CQL queryType to carry a CQL query. 
>We shouldn't decide that now it carries other stuff when the queryType is not CQL.

That is how I understood the situation, nor does it reflect any suggestions *I*'ve written re proposed changes to queryType behaviour.

Prior to the cql-form discussion, queryType defined the syntax of the data passed in the query parameter. If I wanted to send a SPARQL query you would specify the appropriate queryType but still send the query in the query parameter.

My articulation of the change was that queryType could *optionally* define different parameters, not that it must do so. Hence in the above SPARQL example, the query parameter would still be used.

However, you seem to be saying a different queryType *must* define a parameter other than query, so for the SPARQL example, I'd have to define a parameter called "sparqlquery". Could another queryType reuse this parameter? If not, how would we control that? If it would does thia mean CQL has a special status that prevents its query parameter being re-used?

In any case, the above are only proposed changes. The current spec is that queryType defines the content of the query parameter. My new proposal is that the query is still passed via the queryType parameter, but depending on the queryType may use additional parameters too.


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]