The most useful definition of a document I've seen is "a unit
of retreival." Since you can't retrieve the index -- only
summaries of the index, query results from the index, etc. --
the index isn't a document by that definition.
>In the case of the dictionary, of course, one could argue
>that the Dictionary as a whole is also a concrete document,
>since it would be possible to just read it cover to cover.
If we had a protocol to do this, yes...
>Maybe this can be addressed in HTML2, by some process of negotiation
>between server (abstract document) and user/client. e.g the document
>sends something back saying "I will give you a page of text but
>first send me at least one line of ascii". If this is the
>right approach, then we need a means of describing data types and prompts.
>The negotiation might take several exchanges, or it might be done
>by having the server return a small program, something like a decision
>tree, to prompt the user for all meaningful values required for
>the input.
Clarification: this shouldn't impact HTML significantly. It should
impact HTTP, the protocol. Whether the forms description/query
language should become part of HTML isn't clear. I'd say: no, it
should be a separate beast.
Tim mentioned the same scenario, with servers sending out forms,
clients with "forms editors" and complex queries.
The closest thing I've seen to an implementation of this is the
Dynatext browser. There's some sort of query dialog description
language: I think it's an SGML language. So you describe the dialog
with an SGML document. The browser displays toggle buttons, text
fields etc. The user fills in the fields, clicks OK, and the
query results come up in the table of contents window.
Dan