 |
 |
Hi Ray, ad Sessions) Another answer to the session issue is, that unfortunately some (most?) existing Z39.50 Servers don't even maintain the sessions until the Client requests to drop the session. This is causing us a lot of grief in practical applications, where the session and its corresponding result sets suddenly disappears. Since we can't trust sessions to persist anyway, it is easier to program Clients in relation to a truly sessions-less model. ad SOAP vs. URL) There is a place for both methods: SOAP is for "thick" Clients used in specialised applications. The URL solution is a more general enhancement of the OpenURL concept, i.e. simple search and retrieval with "thin" Clients. We could postpone the "White paper", until we have something more tangible to present. For instance as a background paper for the next ZIG. Best regards, Poul Henrik mailto:[log in to unmask] <mailto:[log in to unmask]> -----Original Message----- From: Ray Denenberg [mailto:[log in to unmask]] Sent: Monday, July 23, 2001 10:00 PM To: [log in to unmask] Subject: ZNG discussion I've scanned the discussion over ZNG on the ZIG list. I think a few good points have been made and we should think about how to address them. Joe Zeeman -- See Below. Pieter Von Lierop -- Nothing coherent from him. Kevin Thomas -- His rpn examples can't be ignored, and we need to be sure that we address this in the CQL syntax. Rob Sanderson -- in addition to other issues covered elsewhere, raises the issue that without sessions you cannot predict how long result sets will be available. I suppose the answer is that you can't predict that even with sessions. Jan Veght -- suggests a better marketing name than CQL, in particular, the "C" for "common" should be changed, to allow differentiation from things like XQuery. (On a positive note, say the 'Search/Retrieve web service' marketing label is "brilliant".) Joe Futrelle -- asks why we didn't use XER (actually, he asks what is our feeling about XER). I think our answer is (a) it's not compatible with SOAP, and (b) XER preserves too much of the ASN.1/BER baggage that serves only to make the output heavier and less readable. In a later message, Joe Futrelle asks how does ZNG differ from OAI, other than the fact that it includes search. And he says he would "like to see the ZNG designed so that it can easily serve an interface to OAI harvesters." We talked about this briefly and I think we need to think seriously about it some more. Rob Bull -- presents an alternative (and completely different) approach. I would suggest that another group articulate and implement it. Scan ----- A number of people raise the question why we excluded Scan. The fact that this question is been raised is a clear indication that we haven't done a good enough job explaining what we're doing. The Name "ZNG" ----------------- My initial reaction to the criticism of the name "Z39.50 Next Generation" was to agree, as Matthew said, in retrospect it was a mistake. But I've changed my mind. I agree that the name is perhaps misleading and maybe we should consider changing it later, but not now; it's gotten peoples attention and stirred up debate. If we change it now to something innocuous, our effort is more likely to be ignored. Secrecy --------- I think that the issue of "process", i.e. "secrecy", raised by Joe Zeeman, has been addressed adequately by Mike Taylor. Johan Zeeman wrote: Just because some implementors don't like the distinction doesn't make the distinction irrelevant. (this pertains to the distinction between Search and Present). We need to better articulate that just because we combined these into a single service doesn't mean that we don't recognize the distinction. If a single service is used, the message must still include information to allow the server to decide whether a new search is being made or not, especially since the result set model remains. I think that it is here where we intentionally decided to blur the distinction (rather than search/present). For better or worse we've decided that whether a new search is executed or not is transparent to the protocol. We need to articulate this better. Inventing a new query language to compete with XQL is just dumb. I think Joe is wrong here. XQL (or I presume he means XQuery) right now simply doesn't support the sort of things that Z39.50 needs -- proximity, truncation, etc, or in general, text searching. A standard that lets the same thing be done 2 ways (URL and XML) is going to fail. What's the response to that? (Ralph?) How do you all feel we should respond to these issues? I had suggested that we write a brief paper, but I haven't heard any feedback on this suggestion. Does anyone think it's a good idea? For now, I'll try to keep a running list of and track these issues, until we decide the best way to address them. Please contribute to the list. --Ray -- Ray Denenberg Library of Congress [log in to unmask] 202-707-5795