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 that
forum be? (the ZIG list?) --Ray

"Stevens, Pat" wrote:

> Ray
>
> The answer is that this is an experiment to see if this approach would work.
> If Jo is right, it won't.  I think we should stick to the decision we made.
> We will take in implementers who want to work within the framework outlined.
> 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 a
> standards process to build it.
> pat
>
> -----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 declaration
> that this group was active.  There has been no invitation to participate or
> 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.  For
> instance, the statement that distinct search and present services either "do
> 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 whether
> 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, and
> especially, there is no removal of any "barrier to implementation" - the
> same amount of implementation work is required whether a single message type
> is used or two separate ones .
>
> I would also like to have the rationale for abandoning RPN explained.  This
> 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 attribute
> 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 to
> fail.  Pick one, folks.  My vote would be for SOAP.  Unfortunately, I don't
> seem to get to vote.
>
> J.

--
Ray Denenberg
Library of Congress
[log in to unmask]
202-707-5795