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

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]