Re: Future of meta-indices: site indexing proposal and Perl script
Dave Raggett <dsr@hplb.hpl.hp.com>
Errors-To: listmaster@www0.cern.ch
Date: Tue, 22 Mar 1994 19:18:12 --100
Message-id: <9403221815.AA22873@dragget.hpl.hp.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: dsr@hplb.hpl.hp.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Dave Raggett <dsr@hplb.hpl.hp.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Future of meta-indices: site indexing proposal and Perl script
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1351
> I'm not completely sure this is a good idea, for this information. The
> "IAFA-description"s may run on for some length --- for instance, the entire
> abstract of a technical paper. (FWIW, the IAFA-Publishing Internet Draft
> says that the Description entry on templates should be 'the "abstract" in
> the case of documents'; also, technical papers are starting to appear on
> the Web as hypertext --- see, for instance, AI Technical Report 1315 at
> http://www.ai.mit.edu/people/ellens/why.html, or the Transit project docs
> at http://www.ai.mit.edu/projects/transit/transit_home_page.html, to cite
> two examples close to home).
> Abstracts are clearly metainformation in the general sense, but they seem,
> to my taste at least, a bit heavy-duty for a HEAD request. (Do we really
> want large HEADs to be routinely larger than small documents?)
HTML+ includes the ABSTRACT element for this. The "Summary" HTTP
header should therefore be reserved for a brief description.
At some point in the future we may wish to extend HTTP
to allow clients to request named portions of the document.
Right now the #ID suffix is interpreted by the client, but there
is now reason why with a suitable HTTP method (e.g. "EXTRACT")
the server couldn't extract the contents of the named container
and send that rather than the entire document.
Dave Raggett