 |
 |
I will not be able to come to the meeting butI have the following agenda items with below some additional explanation. 1) SRU versus SRW 2) Parameters versus webservices 3) Self explaining responses. ------ SRU and SRW: I think it is important to agree that SRU and SRW will be and remain basically the same. As a consequence we have to keep the request syntax URL-friendly, but it facilitates supporting both protocols and developing SRU-SRW gateways. The only externally noticable differences between both are: a) the way a request is issued (URL or SOAP-post) b) the response being in a SOAP-envelope or not c) the extra level of escaping "<" and ">" needed for SOAP ---- Parameters versus webservices. I would suggest to be very sparesome (is this an English word?) with adding new webservices where an optional parameter would be sufficient. This allows us to use the same base-url for different functions, which is quite convenient. I think we can already anticipate on possible functions, for which we can reserve a parameter (optional). The specification of the exact usage can be refined later (like we did for CQL). Examples for such parameters are: a) sortfield(s) b) flag to indicate the type of request 1)search, 2) scan, 3) fuzzy 4) search but additional scan or fuzzy list is allowed 5) specific records from resultset etc. c) optional stylesheet reference in response to allow transformation in the browser. I assume also in case of SRW the user will use a webbrowser to see the results and such a reference could smetimes be useful. ---- 3) Self explaining responses A more fundamental issue in my opinion is the question whether the SRU/SRW responses should be self explaining. Like minimizing the need for servers to remember session-context the SRU/SRW protocol would in my view improve when clients/gateways do not have to remember session context either. A client then acts on the response rather than what was requested. A first step is echoing the request parameters in the response (this is an old issue but I cannot remember a decision). In the context of not fully supported optional parameters a self explaining response allows servers = within reasonable limits = to give a "best response" in case they can not retrurn exactly what is requested instead of returning 0 hits or an error message. In my view this will be the main key to interoperability. This may require some extra tags to describe the response but lets first see if there can be agreement on this issue. Example: a client does a search resulting in 0 hits but the server is able to return the result of a scan. Most users would be glad with such a response. For this example the only thing that is required is a tag <indexTerms> sibling to <records> in the searchRetrieveResponse. --- As I will not be attending the meeting, if more clarification is needed please let me know. Theo >>> [log in to unmask] 10-06-02 16:27 >>> Time to start building an agenda for the July 11-12 meeting, and an attendance list. Please see: http://www.loc.gov/z3950/agency/zing/meeting-july02/meeting-july02.html (I'm not publicizing this page, so there is no link to it.) Everyone on this list, please tell me explicitly whether or not you're coming to the meeting (when you know with reasonable certainty) so I can add you to one of the two lists on the attendance page. Also, please send agenda items, whether you're coming or not. --Ray