-----Original Message-----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.
From: Ray Denenberg [mailto:[log in to unmask]]
Sent: Monday, July 23, 2001 10:00 PM
To: [log in to unmask]
Subject: ZNG discussion
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.
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.
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(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.
doesn't make the distinction irrelevant.
If a single service is used, theI 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.
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
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.
Library of Congress
[log in to unmask]