RE: ZNG: "Z39.50 Next Generation"

> > -----Original Message-----
> > From: Robert Sanderson [mailto:azaroth@liverpool.ac.uk]
> > 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.

I concede that as you can request N records starting at point X, where N
can be 0, that present is unnecessary in the ZNG context.

> Nope, no ASN/BER.  Say, are you the marketing guy for ZNG?
No, I just happen to like BER :) So sue me :)

> No multiple record syntaxes.  Mostly because things like USMARC cannot fit
> cleanly into an XML record.  But also because of the conceptual simplicity

We've had no problem mapping Marc into SG/XML.  In fact the LoC site has
our tools for doing this IIRC, and are otherwise freely available.
Anything can be mapped into XML really, and Marc is a comparatively
simple[1] record structure.

1: Compared to something like TEI at any rate.

> 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

I agree entirely on the Extended Services front.

> > 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 must have missed that in the page.  However I think my point still
stands - in a heavy use server such as a university library retaining
result sets across sessions without something to say 'I actually want this
result set recorded' is going to be unmanagable.  The good thing about
sessions is that when the client goes away, so can all the result sets it
created.

Currently, what would be easier and fundamentally the same, would be to
simply allow multiple requests in a single URL. (Which my hacked up syntax
did)  Then instead of saving result sets you can do the initial request
again, and then apply the second request to the results of the first.

As the client end needs to record the name of the resultset, it might just
as well record the original search performed.

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

Scan, Sort, Explain. Complex binary record structures.  Multiple formats
For example, request a 'title only' or 'summary' syntax before retreiving
the entire document.  And for some TEI or EAD documents, you Really Really
want to be able to do this. Same for record segmentation.

GRS1 is extremely useful, especially for reconstructing records from one
syntax in another.

Personally I like sessions, especially when trying to connect to a slow
database. Once hostname is resolved, connected across a potentially laggy
network, reverse namelookuped, logged as connected, gotten init and
occasionally explain information, I can just run searches as I desire,
leaving result sets until I need them later. With a sessionless connect,
the network overhead is repeated for every request.

In terms of gateways/portals, it's also much faster.  Instead of creating
connections to a remote Z served database, you can create one connection
and tunnel all the gatewayed queries down it.

Ditto for record/metadata harvesting.

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

Yes. Exactly :) However people know and use it regardless -- I haven't
seen too many 'Idiot's Guide to Z39.50' books around, ya know.

Rob

-- 
      ,'/:.          Rob Sanderson (azaroth@liverpool.ac.uk)
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Syrinnia:  telnet:  syrinnia.o-r-g.org 7777
____/:::::::::::::.                WWW:  http://syrinnia.o-r-g.org:8000/
I L L U M I N A T I

Received on Monday, 16 July 2001 09:38:26 UTC