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
> 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>
> 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:
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
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@example.com