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