RE: ZNG: "Z39.50 Next Generation"

> -----Original Message-----
> From: Robert Sanderson [mailto:azaroth@liverpool.ac.uk]
>
> Err....
> No session support?  No separate search/present? No ASN/BER ? 
> No multiple
> record syntaxes?  No -scan-?

Nope, no session support.  Sessions were mostly about preserving TCP/IP
connections.  Those connections don't seem to be as valuable as they once
were, so let's drop them between transactions.

Nope, no separate search and present.  No need.

Nope, no ASN/BER.  Say, are you the marketing guy for ZNG?

No multiple record syntaxes.  Mostly because things like USMARC cannot fit
cleanly into an XML record.  But also because of the conceptual simplicity
of using the same record sytax for encoding the records as encodes the
response.

No scan.  That is a loss.  But, there is no reason why we can't write a Scan
service next week.  We just needed to draw a line somewhere.

I do want to repeat my first point above.  A strong, unstated, underlying
philosophy in Z9.50 was that connections were precious.  We stuck ILL into
Z39.50 because we already had a connection open between the ILL requestor
and the likely target of the request; why not use that connection to carry
the ILL request.

Much of the complexity of Z39.50 can be moved into other services once you
get away from doing everything over a single connection.  Extended Services
goes right away.  So do most of the non-core services.  Now we can produce
documentation that focuses on our core business and defers the other stuff
to other services (and other documentation) that the user can adopt, as
needed.


> Getting rid of these makes it next to useless in context. At least you
> didn't cut out search completely (which would make it almost 
> identical to
> OAI).  Exactly how does ZNG preserve anything of the current 
> Z protocol?

ZNG preserves the semantics of Z39.50.  Everything else is fair game.


> Without sessions, resultset storage will be as little 
> implemented as it is
> now.  As you can't predict whether the result set will be needed in 2
> seconds or 2 hours, on any server of significant

Actually, we hope to improve on the current situation with ZNG.  We're
providing a mechanism for the server to tell the client how long it can
expect the result set to survive.


> I understand that the impetus here is to bring it into line 
> with current
> web database structures. As far as I'm concerned, this is a 
> waste of time
> as the current advantages of Z are being cut out.

Tell me what those advantages are.  What are we losing?


> People will just use
> SQL, rather than ZNG as it is proven and established, with a 
> very large
> knowledge and support base already in existance.

Baloney.  SQL sucks and we all know it.  Their grammar sucks nearly as badly
as RPN and they have no protocol for transfering their requests.  Plus, they
have no abstraction mechanism.  Z39.50 rocks!

Ralph

Received on Monday, 16 July 2001 08:58:22 UTC