RE: "Z39.50 Next Generation"

I tried sending this yesterday, but that was while I was unsubscribed.


Joe, you and Denis Lynch are the technical opinion leaders I respect the
most in this group.  You have lead us through some murky areas in the past
and may be doing that now.  I don't think we're in one of those areas now,
but I really want to understand your problems with this proposal.  Your
message below expresses a lot of bitterness about the process and the
result, but little in the way of technical objection that I can respond to.
I'll try to answer your questions as best I can and I hope you'll keep
coming back with more objections until we understand each others positions,
if not actually come to agreement.

> Johan Zeeman wrote:
>
> 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.

To be honest with you, I don't think anyone expected this outcome.  In large
part, that's why we didn't see any need for a larger group.  We looked like
we were headed for the boring solution of XER in SOAP.

In the weeks before our meeting, there were some attempts at use cases and
justifications for a new protocol and they were very uninspiring.  The day
before the meeting, I met with six other people at OCLC to discuss the
likely outcome of the meeting.  They were as uninspired as I was.  The only
real change that would happen would be the addition of an HTTP server to the
mix of servers that we already have.  The proposed changes were viewed as
more disruptive than productive.

At the end of the meeting, I asked the head of our FirstSearch development
group what he would like to see come out of the meeting.  Surprisingly, his
answer was that the thing he wanted most was for Explain to work like it's
supposed to.  He also said that he wanted URL based requests.  I took those
requirements and crafted a one page description of a dream solution and took
it to the meeting.

To make Explain work, I needed to simplify things.  One of the biggest
complexities of Explain is the fact that things differ so much for each
database.  So, out go multiple databases.  The assumption now is that you
connect to a single database.  This makes things much simpler.  Next, since
we've already assumed that XML is our encoding standard, lets drop all the
other record syntaxes.  We get some of that complexity back with a richer
support for schemas, but I'm betting that there won't be as many schemas as
there are record syntaxes now.

I took my page of requirements to the meeting and pushed it hard.  I'd feel
guilty about having hijacked Ray's meeting, except that it was so easy.  The
other attendees were surprisingly willing to accept my proposals.  They were
clearly as uninspired by the direction that we had been heading as I was.

I want to reiterate that point.  The result of our meeting was a surprise to
everyone who attended.  We documented our results as quickly as we could and
got them to the ZIG.


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

Ignore the rationale.  It's not about whether the implementor like or
dislike something.  The question was, can we accomplish the same task with a
simpler request model.

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

Absolutely correct and that information is in this model.  If the search is
simply a reference to the old result set, then no new search is required.

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

Yes, there is a benefit.  There is only one request that needs to be
understood.  With that one request, we can do all the things that we
currently need two requests for.

Joe, you say that our basic premises are wrong, but only give one example.
That means that you have more examples.  Bring them out so that we can
discuss them.  We won't find the holes until you do.


> I would also like to have the rationale for abandoning RPN
> explained.

Because RPN is harder than CCL.  All RPN does is make it easier for
programmers to parse the queries.  So, which would you rather type in:

<rpn><rpnRpnOp><rpn1><op>dog</op></rpn1><rpn2><op>cat</op></rpn2><op>and</op
></rpn1></rpnRpnOp></rpn>

or

dog and cat

Seems like a no-brainer to me.  Now, I can hear some of you saying that all
you need is a simple tool that let's a user type in "dog and cat" and it
will produce that lovely RPN query above.  I don't want to have to use tools
to do simple things.  I'm tired of them.  I don't want to have to use a tool
to make the query and another tool to make the request and another tool to
decode the response and another tool to look at the records.  If there is a
way to do these things without having to invoke some tool at every step,
then I'm for it.

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

I'm not looking to compete with XQL.  Or more properly, I don't think XQL
will ever compete with us.  Their final result will be nearly as ugly as the
RPN query above, only produceable by experts and tool builders.


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

Actually, it wasn't proposed to make URL's easier.  I just didn't see any
reason for all that encoding complexity to make parsing a little easier for
the server.


> If you don't like bib-1,
> then develop new attribute sets designed to work better in the
> Web environment.

Who said anything about bib-1 going away?  I thought you were unhappy about
RPN going away.


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

You know, we're having a similar debate in our church.  Should we go on
having traditional services or should we provide an option for people to
choose between a contemporary service and a traditional one.  The advice of
most of the successful churches in our area is that the more options you can
provide, the more people you will attract.  I think that applies here too.


> Unfortunately, I don't seem to get to vote.
>
> J.

Of course you get a vote.  You will be voting by implementing or not
implementing.  If you decide that there is nothing of value here, then you
continue to run your existing system talking to the same customers that you
already have.

I think this proposal will bring new people to our community.  True, they
won't be bit-compatible with us.  But, as long as the semantics are the same
between these communities, it will be trivial to build gateways between us.

Nowhere in this proposal is there a suggestion that we abandon Z39.50 as it
currently exists.  This is not Z39.50-2002!  This is an experiment, which is
successful, will probably get standardized somehow.

Ralph

Received on Tuesday, 17 July 2001 09:27:13 UTC