W3C home > Mailing lists > Public > www-zig@w3.org > February 2002

RE: Z39.50 on the web (and in print)

From: Robert Sanderson <azaroth@liverpool.ac.uk>
Date: Mon, 25 Feb 2002 10:39:12 +0000 (GMT)
To: Liv Aasa Holm <Liv.A.Holm@jbi.hio.no>
cc: <www-zig@w3.org>
Message-ID: <Pine.LNX.4.33.0202250942450.20483-100000@gondolin.hist.liv.ac.uk>

> I have been following this discussion for a time.  One question to Rob S.: 
> How does a client find your server? That is how does it find the address, 
> the port number, if authentication is needed etc.?  The client will need 
> this BEFORE it can make an INIT to your system.  This is where Explain Lite 
> has been successful.  You can set up your client BEFORE sending an INIT.

I'm not debating the need for friends and neighbours or a database of 
servers.  I'm simply saying that Explain Lite is not up to the job of 
being a replacement of any degree for Explain, and that if the ZIG should 
recommend something other than Explain, it should not be Explain Lite.

There definitely needs to be a standard way to find Z39.50 servers.  
Standard in such a way that the ZIG can recommend that clients be built
against it, otherwise what point is there? I would thus expect that the
requirements of the entire Z39.50 community be taken into account, not
just those of the ONE-2 project.  And in particular the experience of
those projects that /have/ implemented Explain and built clients against
it.  I would also expect it to be at least as forward looking as to 
include support for the attribute architecture if nothing else.

To answer the question, one finds it by doing a search on google, the same 
way you find anything else these days ;)

That said, how does one find your explain lite records? You know in 
advance where they're kept, the same way as you know where my server is.
You then also need to find the documentation on explain-lite to understand 
what is meant, as it's not part of the standard.

> Another point. Explain Lite does not have to be static, by that I mean "no 
> more tags/fields added".  Just add the fields you think are missing, but do 
> not use the existing tags for different content than today.

That can't be done in a sensible manner and isn't strictly true.  It has a 
DTD, and won't validate against it if new tags are added arbitrarily.
I could send off a LONG list of changes (some examples below) or I could 
implement something which is designed with those changes in mind. I 
decided to do the latter, for obvious reasons.

For example the existence of the b_* tags mean that for every new place in 
which I would like to use an attribute, I need to invent new tags. c_* d_* 
z_* ...  Which is ... well ... not very XML like. Why not just use the 
same tags as for <search_attributes>?

If I wanted to have multiple languages, I would need to invent new tags 
for each new language for each existing text holding tag. <description_en> 
<description_fr> and so forth.  I want to be able say that my server 
supports an attribute set with X OID with the following attributes based 
off of UTIL-1 and XD-1 ... many -many- more tags.
If I have multiple sets of attributes all of which point at the same index 
(for example BIB1 author and BIB2 author) then I have no way to express 
that these are just aliases for the same type of search. Sort... more tags 
required. Extended Services? Lets not even go there!

When I have 30+ databases on my machine, each of which has 20+ 
possible searches and another 20+ aliases for them, are you Really Sure 
you want all that info in one go?  Wouldn't you rather be able to search, 
scan and sort it like a regular database?

The list just goes on and these are things that simply need to be able to 
be expressed in my opinion.

Rob S

      ,'/:.          Rob Sanderson (azaroth@liverpool.ac.uk)
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Twin Cathedrals:  telnet: liverpool.o-r-g.org 7777
____/:::::::::::::.              WWW:  http://liverpool.o-r-g.org:8000/
Received on Monday, 25 February 2002 05:42:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:03 UTC