Print

Print


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.