Hi Ray, The only reason that we have gotten so far in such a short time, is because we restricted the ZNG group to a few open-minded and well-informed implementers - and excluded the filibusters. Please keep the ZNG list private and let others comment on ZNG on the public ZIG list. (It is encouraging to see this much activity on the ZIG list just because of our initiative). Let others form their own private groups and propose their own competing solutions, so that the World can hopefully pick an ultimate winner among several alternatives. Best regards, Poul Henrik -----Original Message----- From: Ray Denenberg [mailto:[log in to unmask]] Sent: Friday, July 13, 2001 3:53 PM 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.