Perhaps what I dislike is that ISINDEX is a boolean - either you have it
or you don't. Instead what I (think !) I want is:
To the end user everything is searchable.
Simple user agents can defer as much as possible to the server:
ie I just pass a search string to the server and let it sort
everything out.
Sophisticated user agents can check a documents class to determine
what sort of searching makes sense, then can frame a "sensible"
set of queries.
--> ie no specific ISINDEX tagging. Instead merely tag with the class,
and give the user agent freedom to decide whether or not it wishes to use
the information it can derive from the class.
What I think I am going to implement (within the current WWW framework) is
an extension to the httpd configuration file that maps documents names
to search method.ie as well as
map /* /usr/local/lib/WWW/*
I have:
search /* wais <some parameters>
so that searches initiated from a particular document or zone of the
document space can be searched by a particular method. This gives me
the ability for do such things as sectional indices and multiple
search methods within a single server.
>> Instead of the ISINDEX tag, I think we need an INPUT tag. ISINDEX is quite
>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.
I agree this is the tip of the iceberg.
The point I was trying to make is that smart documents are conceptually
very different from searchable documents, and thus there should be a way
of implementing smart docs without overloading ISINDEX.
I'm not sure about keeping this in document class. How useful is a class
that only has one instance ? (assuming that forms are generally one offs)
I'm inclined to prefer an in-line representation: just as I can currently
mark a point where text should be highlighted within a document, so I
should be able to mark a point where text should be inputted.
Kevin Hoadley, Rutherford Appleton Lab, khoadley@ib.rl.ac.uk