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:rd...@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:lev...@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:rd...@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:lev...@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

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?