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

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

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

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 Denenberg
Library of Congress
[log in to unmask]