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.
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
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.