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] Multiple Query Types


You are absolutely correct, we are coming at this from different points
of view.  The issue is that we own the SRU standard and have the moral
authority to tinker with it.  We do not own OpenSearch and have no
authority to tinker with it.

So, my intent is to look at what OpenSearch does well and get it into
SRU.

Ralph

-----Original Message-----
From: Farrukh Najmi [mailto:farrukh@wellfleetsoftware.com] 
Sent: Tuesday, December 04, 2007 10:44 AM
To: LeVan,Ralph
Cc: search-ws@lists.oasis-open.org
Subject: Re: [search-ws] Multiple Query Types


Perhaps we have a recurring disconnect between us because:

1. I am coming from the viewpoint that OpenSearch should be the starting

point for search interface and ATOM 1.0 should be the starting point for

response and all else (e.g. CQL etc) should be our value add. I believe 
this is what the broader user community is looking for. I believe 
OpenSearch and ATOM have deficiencies that can easily be worked around 
for now and are good enough for Search-WS.

2. You seem to be coming from a viewpoint that current SRU protocol 
should be the starting point for every thing and that OpenSearch and 
ATOM are unusably deficient

I understand completely that that Explain is equivalent to OpenSearch 
description document. That was precisely my point. T^hat if it is 
equivalent then we should use Open Search as the starting point and fix 
any deficiencies rather than starting with SRY equivalent.

The same goes for search response format. I believe that the starting 
point should be ATOM 1.0 and any deficiencies should be worked around 
and fed back to the IETF spec authors and ATOM community.



LeVan,Ralph wrote:
> I don't believe you understand what an Explain record is.  The Explain
> record is the equivalent of an OpenSearch document description.  So,
> when you say:
>   
>>> Instead, the Explain record, which already lists the supported query
>>>       
>
>   
>>> types, also specify the name of the associated query parameter.
>>>
>>>       
>> -1. We should use the OpenSearch description document for describing 
>> queries and their params.
>>     
>
> You have either said that I was wrong and that you should do what I
said
> or you somehow think that OpenSearch document descriptions are
superior
> to Explain records and should be used instead.  The number of
> deficiencies in OpenSearch document descriptions are numerous and
> nothing that we can correct.  So, wherever you have said "use
OpenSearch
> document descriptions", I will assume you meant "use Explain".
>
> Ralph
>
> -----Original Message-----
> From: Farrukh Najmi [mailto:farrukh@wellfleetsoftware.com] 
> Sent: Monday, December 03, 2007 4:55 PM
> To: LeVan,Ralph
> Cc: search-ws@lists.oasis-open.org
> Subject: Re: [search-ws] Multiple Query Types
>
>
> IMHO, We should really be looking at OpenSearch and OpenSearch 
> description documents for describing the queries that are supported by
a
>
> server and what parameters the query supports. This implies to me that

> we not do the equivalent functionality elsewhere (e.g. Explain
Record).
>
>
> LeVan,Ralph wrote:
>   
>> I'd like to bring up the topic of multiple query types again.
>>
>> I think we have eliminated the use of a query-type parameter as a 
>> solution. This would have used the query parameter to carry queries
of
>>     
>
>   
>> all types and the query-type parameter would have specified how the 
>> query was to be interpreted. Explain records would have listed the 
>> types of queries supported by the server. The objection to this 
>> parameter is that it adds another parameter to the query (and the 
>> documentation).
>>
>> A simpler solution is to use the name of the query parameter itself
to
>>     
>
>   
>> indicate the type of query. For instance, our current query parameter

>> might be renamed CQLQuery and a new query parameter of LuceneQuery 
>> might be specified to support Lucene queries.
>>
>> One way to do this would be to have the standard specify the
parameter
>>     
>
>   
>> to be used for every type of query we can think of.
>>
>>     
>
> I think above is inappropriate and unworkable.
>
>   
>> The Explain record for the database would again list the supported 
>> query types. This simplifies interoperability, but leaves the 
>> standards body with the perpetual task of adding new search types.
>>
>>     
>
> +1
>
>   
>> My preference is that the standards body not specify the name of the 
>> query parameters.
>>
>>     
>
> +1
>
>   
>> Instead, the Explain record, which already lists the supported query 
>> types, also specify the name of the associated query parameter.
>>
>>     
>
> -1. We should use the OpenSearch description document for describing 
> queries and their params.
>
>   
>> This allows for much easier local extensibility.
>>
>> The objection to this scheme is that trivial interoperability goes 
>> away: SRU URLs cannot be constructed without reference to the Explain

>> record.
>>
>> So, here's my compromise position: do it my way. Well, that and have 
>> the standards body create a profile where we specify the names of the

>> parameters for query types that we think might be useful/common.
>>
>>     
>
> I am not sure what "do it my way" above refers to - so I can't
comment.
>
>   
>> Feedback would be appreciated!
>>
>> Ralph
>>
>>     
>
>
>   


-- 
Regards,
Farrukh Najmi

Web: http://www.wellfleetsoftware.com




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