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] queryn: Some further comments


Title: RE: [search-ws] queryn: Some further comments

The queryN parameter is peculiar to the cql-form queryType and will not be going into the standard.  So, there will be no standard behavior based on that parameter.

 

Ralph

 

From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Monday, December 20, 2010 2:15 PM
To: LeVan,Ralph; Hammond,Tony; 'Matthew Dovey'; 'OASIS SWS TC'
Subject: RE: [search-ws] queryn: Some further comments

 

The presence of the queryN parameter would signal that there is no query.  --Ray

 

From: LeVan,Ralph [mailto:levan@oclc.org]
Sent: Monday, December 20, 2010 11:32 AM
To: Denenberg, Ray; Hammond,Tony; Matthew Dovey; OASIS SWS TC
Subject: RE: [search-ws] queryn: Some further comments

 

Of course it is a new queryType.  Otherwise, the query processor is going to be looking for a query parameter.

 

Ralph

 

From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Monday, December 20, 2010 11:23 AM
To: LeVan,Ralph; Hammond,Tony; 'Matthew Dovey'; 'OASIS SWS TC'
Subject: RE: [search-ws] queryn: Some further comments

 

But this is not really a query type, it's a pseudo query type.    The idea is that in lieu of the query in the query parameter,  the cql query will be represented by SRU parameters.    Those SRU parameters cannot technically be considered to constitute a query  - a query goes in the query parameter.  And they cannot be considered an extension either, as we already have naming conventions for extensions and we'd have to revise those considerably.  

The only reason we're talking about queryType is that we've discussed coming up with a query name, which we've been calling cql-form, and if that's the query type, then there is no query parameter  and the form parameters are supplied instead.    And now, I think we have (tentatively) agreed that the queryN parameter is probably useful, meaning that perhaps we don't even need this query type mechanism to signal the  presence of the form parameters and we don't really need a query type at all.

--Ray

 

From: LeVan,Ralph [mailto:levan@oclc.org]
Sent: Monday, December 20, 2010 9:40 AM
To: Denenberg, Ray; Hammond,Tony; Matthew Dovey; OASIS SWS TC
Subject: RE: [search-ws] queryn: Some further comments

 

While I’m okay with this as a new queryType, I don’t think it belongs in the standard.

 

If this standard has any value, there will be many queryTypes over the years.  They will not go into the standard.  We’ll agree on a way to name the queryTypes so we don’t have to coordinate those names (I’m thinking a URI) and associated with those queryTypes will be the way they get encoded in the request and (more importantly for omitting from the standard) how they get echoed back in the response.  QueryTypes also need to define their diagnostics.

 

QueryTypes will need some way to be echoed back in the searchRetrieveResponse.  In the case of cql-form, we’re talking about the stupidest client in the world and it will need to have everything that it sent be echoed back so that it can appear in the next screen.  There is no place for repeating q** parms in <echoedSearchRetrieveRequest> and I will resist adding it.  That means that the echoed q** parms will have to appear in the <extraResponseData> element.  That’s a place for extensibility, not for standard behavior.

 

I’m happy to keep working on this, but I’d prefer that we think of this as Nature’s extension to the standard, not as something we want as part of the base standard.

 

Ralph

 

From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Friday, December 17, 2010 5:47 PM
To: LeVan,Ralph; Hammond,Tony; 'Matthew Dovey'; 'OASIS SWS TC'
Subject: RE: [search-ws] queryn: Some further comments

 

If all the hidden fields and all the filled in fields get returned that's good enough.  If some empty fields don't get returned I don't see that as a major problem (might be a minor problem but I don't think we have to deal with it).

 

Anyway I'm done for the week but sure would like to move forward on this next week if you all will be around, in fact if we are going to do this (and I think we should) then I would want to move aggressively towards getting this integegrated into the spec. 

 

Tony  - I think that Ralph and I (and I presume Matthew) are comfortable with this model, as we understand it. I sense that you (ironically) still see modeling problems, with server preprocessing?  Can you further articulate?  

 

--Ray

 

 

 

 

From: LeVan,Ralph [mailto:levan@oclc.org]
Sent: Friday, December 17, 2010 5:28 PM
To: Denenberg, Ray; Hammond,Tony; Matthew Dovey; OASIS SWS TC
Subject: RE: [search-ws] queryn: Some further comments

 

I’m not prepared to go quite as far as you and call it form-based SRU, but we’re very close.  Right now I’m assuming that all the non-query based parms are being provided by hidden fields (which always get returned).  Any fields with values will be returned.  The only tricky part is coping with empty/unselected fields that might not get returned.

 

To respond to your particular question, so what?  If the form designer had some sort of field for the user to pick a syntax and nothing got sent in response to the user not picking a syntax, what’s the harm?  If the form designer thought that the parm MUST be returned, then she can specify the field in the form appropriately.  At worst, this is a bug in the form design, but not a problem for the server.

 

Ralph

 

From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Friday, December 17, 2010 5:18 PM
To: LeVan,Ralph; Hammond,Tony; 'Matthew Dovey'; 'OASIS SWS TC'
Subject: RE: [search-ws] queryn: Some further comments

 

That's fine, but do you agree with my basic understanding of this model, that it's form-based SRU?

 

Now suppose the form has a hidden field for record syntax with value DC.  Thus the server has set it up with the intention that when the form is sent it will include  '&recordSyntax=dc'.  Is it possible (likely?) that the browser will decide to suppress that field?

 

From: LeVan,Ralph [mailto:levan@oclc.org]
Sent: Friday, December 17, 2010 5:10 PM
To: Denenberg, Ray; Hammond,Tony; Matthew Dovey; OASIS SWS TC
Subject: RE: [search-ws] queryn: Some further comments

 

Browsers ALWAYS decide what fields to send.  They don’t want to send a bunch of empty parameters if they can avoid it.  This is not an option we can control.

 

Ralph

 

From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Friday, December 17, 2010 5:00 PM
To: LeVan,Ralph; Hammond,Tony; 'Matthew Dovey'; 'OASIS SWS TC'
Subject: RE: [search-ws] queryn: Some further comments

 

I see this as  form-based SRU.  I'm not sure why there even needs to be browser intervention (deciding what fields to send).  The form can give the user the choice, say, of record sytax, or it can treat the record sytax as a hidden field and send it. The form can hide the queryType (cqlForm) and so on.  Right?  After all, isn't the point of this for dumb clients so they don' t have to do anything, just retrieve a form, get it filled out by the user, and send it? 

**************************************************************



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