Re: ISINDEX on documents

Tim Berners-Lee <timbl@www3.cern.ch>
Date: Mon, 16 Nov 92 15:18:18 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-id: <9211161418.AA02518@www3.cern.ch>
To: "KHOADLEY" (KHOADLEY at UKACRL) <KHOADLEY@ib.rl.ac.uk>
Subject: Re: ISINDEX on documents
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>  Date:       Fri, 13 Nov 92 09:42:56 GMT
>  From: "KHOADLEY" (KHOADLEY at UKACRL)        <KHOADLEY@ib.rl.ac.uk>
...
>  There seems little reason to me for the ISINDEX tag. Searching consists of
>  two components: the client constructing a list of queries designed to
>  retrieve the relevant information, and the server receving and processing
>  those queries. Once you start to consider a single user initiated search
>  generated multiple queries there seems to be little point in tieing searches
>  down to particular tagged documents.
>  (of course once a search generates multiple queries it can receive multiple
>  replies. AS these replies could come from different servers it becomes the
>  responsibility of the client end to aggregate the replies into something
>  useful to return to the user: a selection panel for instance).

Every seach needs to search SOMETHING.  Like it has to search a particular  
database or index.  Some servers support thousands of "virtual" indexes. How  
can you express this in a search? The answer is that indexes are names just  
like documents. we then have a convention that if you try to retrieve an index  
as a document, you get back a description of it. This latter is something  
missing for example from WAIS where you have to look up the SOURCE file for a  
database in a totally differents server which may be out of sync (and, being  
centralized, doesn't scale).

If you regard a query as something which is just thrown at the server, then you  
can't allow a ruch enough world of virtual search servers. This was a problem  
with the gopher protocol which causes the Gopher guys to make a  
non-back-compatible sudden change in the protocol spec to introduce an index  
name. 


>  I'd like to see the ISINDEX tag dropped: the client is free to construct
>  whatever queries they wish, using the existing HTTP query mechanism.
>  

>  Instead of the ISINDEX tag, I think we need an INPUT tag. ISINDEX is quite
>  used for purposes other than searching, eg. for "smart" documents or
>  to calculate square roots ! (an example familiar to those at the HEPix
>  meeting ...). However using a tag that appears to have been intended for
>  search purpose for something different is confusing to the end user: ie
>  the page asks for the value you wish to square root, whilst the client
>  prompts you for a string to search for ....
>  

>  Perhaps the following could be useful:
>             <INPUT VAR=x>Please enter your name</INPUT>
>             <DONEINPUT>
>  ie a series of input fields with associated labels, and a button to say
>  you have finished and now send the query. This opens the possibility
>  of forms based pages generating smart documents. How you send the input is
>  a different matter; maybe:
>      http://somehost.somewhere/some/path?x=xxxx+y=yyyy+z=zzzz

This is the tip of the iceberg.  I think the onlywy to do it generally is (see  
my previous message) to have typed queries, and generic editors for them.
The case above would become something like
<ISINDEX TYPE="iana:/www/classes/query/personalinfo">
The type would also be retrievable like a document, and if you had a generic
query language language, you would get back a description of the query language  
supported. A generic client could use that to generate the form to be filled in  
by a user.

>  Kevin Hoadley, Rutherford Appleton Lab, khoadley@ib.rl.ac.uk
>  


Tim Berners-Lee