Ray
My personal reading is that most of this discussion is happening on the ZIG
list, I'm not sure that we have to answer each and every objection.
I think Poul Henrik suggested in a later post that the paper might be
delayed until the ZIG meeting. I agree, I believe that at this point we
have outlined the experiment. We should do the experiment and then write up
the results.
pat
-----Original Message-----
From: Ray Denenberg [mailto:[log in to unmask]]
Sent: Monday, July 23, 2001 4: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
|