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

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

From: Sebastian Hammer <quinn@indexdata.dk>
Date: Fri, 22 Feb 2002 23:55:08 +0100
Message-Id: <>
To: Robert Sanderson <azaroth@liverpool.ac.uk>
Cc: Mike Taylor <mike@tecc.co.uk>, <www-zig@w3.org>

So is the assumption that this model would be used both for servers 
describing themselves and for Friends & Neighbours? My exhuberant comment 
to Mike was intended to yield a F&N scheme first. Yours seems more 
Explain-oriented (but in a good way).

At 16:18 22-02-2002 +0000, Robert Sanderson wrote:

>   <indexdetails>
>      <index search="true" scan="true" sort="true" id="ghlau-mailarchive-1">
>        <name>author</name>
>        <title lang="en" primary="true">Author</title>
>        <type>author</type>
>        <map attributeset="BIB-1" primary="true">
>           <use>1</use><posit>3</posit> <struct>6</struct>
>        </map>
>      </index>

To produce something this detailed would require a fairly steady hand on 
the part of the server operator... remember, many server operators are 
basically people running shrink-wrapped software, and not all of that 
software will be smart enough to produce this automatically (to require 
that would be to set the bar too high, I think). Could you imagine this 
kind of description "dumbing down" to the level where it just asserts that 
this and this and this attribute (combination) is valid on the server, and 
leave the client to figure out what they are. What I'm after, I guess, is a 
record that can be simple enough that it can be produced from the outside 
using automated probing or manual testing...

Why? Again, because while the individual server operator doesn't have much 
of a business case for providing this info, there are good reasons why 
others might want to document your server... and they may not have the 
benefit of knowing what to call your indexes. How about allowing both?


Sebastian Hammer, Index Data <http://www.indexdata.dk/>
Ph: +45 3341 0100, Fax: +45 3341 0101
Received on Friday, 22 February 2002 17:54:54 UTC

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