- From: Robert Sanderson <azaroth@liverpool.ac.uk>
- Date: Mon, 16 Jul 2001 14:34:35 +0100 (BST)
- To: "LeVan,Ralph" <levan@oclc.org>
- cc: "ZIG Mailing List (E-mail)" <www-zig@w3.org>
> > -----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