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: Call Monday, January 10; cql-form options


We have a conference call Monday morning, January 10.  I will post a draft agenda tomorrow afternoon, meanwhile please suggest agenda items. 

One item for discussion is the cql-form query.  We have the following suggested approaches on the table.

1. Ralph's suggestion that query be removed as a first class sru parameter.  Every query type lists parameters that occur for that query - CQL would list 'query' as a parameter.

2. My suggested approach: query remains a first class parameter but becomes optional. If the query parameter is included then the query is assumed to be contained (as a string) within the query parameter. (And if so, if queryType is omitted, it is assumed to be a cql query.)  If the query parameter is omitted, then queryType must occur and there must be one or more parameters which are defined for the query type. (So there is introduced an informal distinction between string and parameterized queries, depending on whether the query parameter is present.)

3.  Tony's suggestion that there be a preprocessing phase added to the protocol model.  However this has not been fully articluated, and we really need to understand it better. 


I wish to comment that I had proposed the second approach before Ralph proposed the first, at which point I said that I liked Ralph's better, but I have changed my mind on that: the problem is, there would need to be some way to allow requests where there is no queryType parameter (for compatibility). Essentially you want to say "if queryType is omitted then there must be a query parameter" but you can't say that because this approach writes the query parameter out of the protocol.  I am also sympathetic to Tony's observation that writing the query parameter out of the protocol risks destabalizing the protocol.  So I am back to favoring approach 2.  

Please comment, and in any case this will be on the agenda for discussion Monday.

--Ray




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