RE: ZNG: "Z39.50 Next Generation" (fwd)

I realised that this and the previous message didn't get to the list
either.

Rob

---------- Forwarded message ----------
Date: Mon, 16 Jul 2001 13:50:44 +0100 (BST)
From: Robert Sanderson <azaroth@liverpool.ac.uk>
To: "LeVan,Ralph" <levan@oclc.org>
Subject: RE: ZNG: "Z39.50 Next Generation"


> What is the advantage to the encoding complexity?  What can you do with it
> that you can't do with the simpler encoding?

zng.cgi?field1=any&term1=cheshire&bool1=NOT&field2=any&term2=cat&sortfield=
title&maxrecords=25&firstrecord=1

(Find the first 25 records that match 'cheshire' but not 'cat', sorted
alphabetically by title)

It doesn't require server side interpretation of the 'common command
language' just mapping directly into a standard Z query.  Anyone can
construct a simple URL as above, whereas creating widespread use of a
particular query language seems more fraught with difficulties.

My, admittedly very quickly hacked up, specification is more easily
extended, and wouldn't break previous versions of ZNG. For example, to add
probabalistic searches, or specific proximity searches, or other
unforeseen type of search, currently you'd need to extend the query
language and then make sure that everyone knows about the changes, updates
their parser and so forth.
If it just takes adding in a new operator to be recognised in the 'operN'
fields, this is a trivial task. This can be acknowledged in the explain
record as well.

The XML descriptive record obviously needs to be defined better than just
'something like Explain Lite', but my minimalist description below would
allow the following:

* Connect with a simple web client, gather information about the
underlying Z db, and then query via Z or http.
* Describe which types of query (search/scan/sort etc) are supported.
* Everything else Explain does.

For full two way compatability, the URL to this xml record should probably
be in the description field of the Z explain as well.

There's not really enough information on the current page to give
specifics, but there's not many implementers currently I imagine that
-don't- have some sort of web interface.  If it were just a matter of
tinkering with the names of the CGI fields rather than implementing a
whole new set of routines, I feel that everyone will be more supportive.

Hence my comment that it's simply an implementer's agreement over how to
name web scripts that interpret existing Z databases.

Rob.

> > Why the changes to the specification?  Why not create a system which
> > simply overlays the current protocol?

> > Overload it to allow a specific search to retreive the > 'Explain
> Lite' xml > record, which would include the supported query types as
> Init > does now, > and the location of the Real Z database if there is
> one.


-- 
      ,'/:.          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 Tuesday, 17 July 2001 10:13:02 UTC