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, [email protected]
>
Tim Berners-Lee