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

["Hammond, Tony" <t.hammond@nature.com>]

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

> 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.

Well we certainly don't need (and are not asking for) any Nature extension to SRU. I guess we can go back to base and define our own &Mickey= &Mouse= parameters just like everybody else.

Tony



-----Original Message-----
From: LeVan,Ralph [mailto:levan@oclc.org]
Sent: Mon 12/20/2010 2:39 PM
To: Ray Denenberg, Library of Congress; 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? 

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

********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************