Re: Including files

foti@morgan.com (Lewis Foti)

Mail folder: WWW Talk Apr 94-present
Next message: F ALBERT: "HTML Question"
Previous message: Daniel W. Connolly: "Effective ways to comment on the HTML 2.0 spec"
Maybe in reply to: John C. Mallery: "Including files"
Reply: Gavin Nicol: "Re: Including files"

Errors-To: listmaster@www0.cern.ch
Date: Thu, 9 Jun 1994 15:13:59 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406091405.ZM10814@is.morgan.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: foti@morgan.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: foti@morgan.com (Lewis Foti)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Including files
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: Z-Mail (2.1.3 10feb93)
X-Mailer: Z-Mail (2.1.3 10feb93)

On Jun 9,  8:34am, Rainer Klute wrote:
> Subject: Re: Including files
> >> >One extension to HTML that I think would be very usefule would be a
> >> >generalisation of the <img src="URL"> markup.  Ideally I would like a
marku
> p
> >> >which would allow the inclusion of any file type e.g. <include
src="URL">.
> >
> >> For handling on the client end, things get more complicated.  The core
> >> issue is:  what does it mean to "include" a document of type X into an
HTML
> >
> >> Is this meaningful?  What does mean to have more than one [pick your
favorit
> e
> >> construct] in an HTML document?
> >
> >Whatever would happen when you created a single HTML document should happen
> >when you include subdocuments.  This means that its up to the user to write
> >"partial" HTML documents and/or the browser could ignore the second HEAD
pair
> >(if everyone used HEAD) and just ignore the BODY.  Since the latter
probably
> >isn't DTD compliant, its up to the user to make sure the document looks
right.
>
> It's far more complicated. (But that shouldn't prevent us from
> specifying and implementing it.) The general case is to include
> only part of the document, for example just a single paragraph from
> someone else's larger work. Or even the whole document - which
> would in this case mean the <BODY> element, but without the <BODY>
> tags. We first need to have a specification on how to reference a
> certain part of a document and second have servers being able to
> extract the referenced part from the HTML file and put it on the
> wire.

This is a more complicated approach than I think is warrented.  Including only
part of an original document (that had not been intended for inclusion) is a
far more general problem.  I'm not sure that including part of a document is
meaningful, what do you expect to see if you include bytes 104255 to 122351
from a gif file?

The advantage of the include markup would be that the user wouldnot have to
click on a link to follow it.  Simply openeing the document would force the
following of the include links.  If the link is to something like a postscript
document (or an Excel spreadsheet) then I would expect the appropriate viewer
to be spawned.  If it were to a file which the client can interpret then the
output would be displayed inline.  (In fact the include directive might have
the ability to specify if the display was to be inline or with a seperate
viewer).  The issues which do need to be resolved are those of interpreting
included documents which are displayed inline, an example of this is how to
handle an included html document.  The browser would know the context as it
would have executed the include markup, and so can distinguish the included
document from a syntax error in a single document.  (This assumes that the
include is executed by the client not the server).

regards

Lewis