I think this list should be for people willing to experimentally implement
within this framework. So, I would say The ZIG list can carry discussion
about what's wrong with this approach and serve as a forum for other
possible experiments. Let's get our complete definition done, publish it.
Then open the list to other implementers like Alan.
But, I believe that you in particular need to stress the points I made in
the first paragraph to the list, because you organized the meeting. Others
of us can support you.
From: Ray Denenberg [mailto:[log in to unmask]]
Sent: Friday, July 13, 2001 10:22 AM
To: [log in to unmask]
Subject: Re: [Fwd: Re: "Z39.50 Next Generation"]
Pat -- I'm not trying to answer Joe right now, I'm asking whether this list
should serve as a (selective) forum for this sort of discussion or should we
keep it strictly to the ZNG implementors for now, and if so, where should
forum be? (the ZIG list?) --Ray
"Stevens, Pat" wrote:
> The answer is that this is an experiment to see if this approach would
> If Jo is right, it won't. I think we should stick to the decision we
> We will take in implementers who want to work within the framework
> After we try it out, we will be in a better position to know if this can
> move us forward.
> At this point, we are experimenting towards a Z39.50 ng not going through
> standards process to build it.
> -----Original Message-----
> From: Ray Denenberg [mailto:[log in to unmask]]
> Sent: Friday, July 13, 2001 9:53 AM
> To: [log in to unmask]
> Subject: [Fwd: Re: "Z39.50 Next Generation"]
> Please give me opinions on whether I should subscribe people to this list
> (on a
> selective basis) like Joe, who is disgruntled about this whole thing (see
> below), or Alan Kent, who I suspect would like to participate, etc. --Ray
> -------- Original Message --------
> From: "Johan Zeeman" <[log in to unmask]>
> Subject: Re: "Z39.50 Next Generation"
> To: <[log in to unmask]>
> I am pretty unhappy at having this sprung upon us as a fait accompli by a
> really quite secretive group of implementors. There has been no
> that this group was active. There has been no invitation to participate
> be kept informed. There has been no discussion of requirements. There has
> been no attempt to arrive at any kind of consensus on technical approaches
> to a problem that many, if not all of us, wish to see addressed.
> I think that some of the basic premises of the group are simply wrong.
> instance, the statement that distinct search and present services either
> not fit well in the contemporary implementation-environment" or "are
> outmoded". Just because some implementors don't like the distinction
> doesn't make the distinction irrelevant. If a single service is used, the
> message must still include information to allow the server to decide
> a new search is being made or not, especially since the result set model
> remains. The is little benefit in rolling these into a single message,
> especially, there is no removal of any "barrier to implementation" - the
> same amount of implementation work is required whether a single message
> is used or two separate ones .
> I would also like to have the rationale for abandoning RPN explained.
> strikes me as a serious loss, especially as RPN can easily be carried in
> XML. Inventing a new query language to compete with XQL is just dumb. We
> all know which will win. If the justification is, as I suspect, to allow
> queries to be carried in URLs then I think the requirement for URL support
> should be re-examined. If you don't like bib-1, then develop new
> sets designed to work better in the Web environment.
> A standard that lets the same thing be done 2 ways (URL and XML) is going
> fail. Pick one, folks. My vote would be for SOAP. Unfortunately, I
> seem to get to vote.
Library of Congress
[log in to unmask]