Re: ISINDEX on documents
Tim Berners-Lee (timbl@www3.cern.ch)
Mon, 16 Nov 92 15:18:18 +0100
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
> 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