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


> 1) What do we say about the "query" parameter in the standard?
> 2) How do we recognize a searchRetrieve request in the absence of a
> "query" parameter?

We had this all worked out December 28 (I went back and looked at the
emails) and then there were a few "destabalizing" suggestions, so I am going
to suggest that we go back in time to that point:

 - There has to be EITHER a query parameter or queryType parameter.  We
recognize searchRetrieve by the presence of EITHER parameter. Everyone was
happy with that. (In particular, you Ralph.)

- If there is a query parameter: The value of the query parameter is the
query string. The parameter queryType will be included if the query is of
type other than cql and may be omitted or included for a cql query.

- If there is no query parameter: The queryType parameter MUST occur and
there MUST be one or more parameters in the request as specified by the
specification for that query type.

- Every query type (other than well-known querie types, e.g. 'cql') will
have URI and in  explain you assign it a short name that is to be used in
the queryType parameter when accessing that server.  

OK?

--Ray





> 
> I think the question you raise below is #3
> 
> 3) should query processing be modeled in SRU?
> 
> I claim that the answer is "no".  We probably need to acknowledge the
> existence of a database service in our model and relegate the
> processing of queries to the database.  We absolutely do NOT want to
> add a preprocessing step to our model whose only purpose is to convert
> non-CQL queries into CQL queries.  Not all queryTypes will be
> convertible into CQL.
> 
> 
> >  Where we left of (before my
> > message yesterday) was that Tony had suggested that he wanted it
> modeled in
> > terms of pre-processing.  So that the query would be transmitted via
> > parameters, i.e. in "form' form, and then the server would convert
> those
> > parameters into a cql query, and process it as a conventional cql
> query.
> >
> > What we don't understand is: is this conversion (a) supposed to be
> visible
> > to the protocol, or (b) is it something that the server is free to do
> if it
> > chooses but is invisible to the protocol.
> >
> > You (Ralph) and I balk at the prospect of (a), and we are not clear
> what
> > Tony's position is, but it seems that that is what he is advocating,
> an
> > explicit modification to the protocol model to accommodate this
> conversion.
> > Tony will have to weigh in.
> >
> > The other issue was ....
> >
> > To remove the query parameter or not.  You (Ralph) suggested that we
> can
> > eliminate the query parameter and make it a query-specific parameter,
> > specifically, THE query-specific parameter for CQL.  While I
> initially
> went
> > along with the idea, Tony objected, and I agree with his objection.
> 
> That's problems 1 and 2 rolled together.  Let's split them apart.
> 
> Ralph
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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