Re: Including files

lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
Errors-To: listmaster@www0.cern.ch
Date: Thu, 9 Jun 1994 18:19:37 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <94060917133871@cguv5.cgu.mcc.ac.uk>
Errors-To: listmaster@www0.cern.ch
Reply-To: lilley@v5.cgu.mcc.ac.uk
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Including files
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

David.J.Heiland said:

>  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.

No, this would be a bad idea. The original suggestion was a syntax of the form 
<include src="URL">. So there is nothing to prevent that URL being fetched as a 
standalone document, since it has a URL. [Equally, this syntax implies client 
side processing, sing the URL to include might well be on a different server to 
the main document].

Following your suggestion would allow servers to have non-compliant documents 
whose intention was as boilerplate text but which would not work as standalone 
documents.

A better option would be to have whole documents. Then look for <head>, if found 
strip off everything from <head> to </head>. Look for <body>, if found strip it 
off and make a note to look for </body> at the end after it has been included.

While this would probably work, I am not sure that it is desirable. If a part of 
a document is all self contained and has it's own URL, why not just put in a 
link to it which the reader can follow or not as needed? This also neatly avoids 
the issue of what to do if the main document is retrieved OK but the included 
document is not.

Maybe we could standardise on displaying the CERN logo inline in such 
circumstances ;-)

Including small fragments is really a separate issue. Such fragments - a single 
paragraph, a couple of list items - should not be externally accessible so 
should be all done on the server side. The files stored on the server may then 
NOT be complete compliant documents in their own right, which is not necessarily 
a problem provided what is delivered to the client IS.

Given that we have singularly failed to learn from the experiences of 20+ years 
of programming language design and are still effectively at the "cut and paste  
school of programming" stage with all the attendant problems of consistency, 
maintainability and duplication of work, I would like to see this issue tackled 
so that editing of a standard fragment is only done once and then applied 
consitently to update all documents that use it.

This is of course a server issue rather than an HTML issue, because it is up to 
the server to maintain data in whatever format is best suited, as long as HTML 
is delivered to the client. Yet it is also an HTML issue, because the document 
author risks losing the benefit of structured editors to maintain the documents, 
hust as they are becoming available.

Previously, servers such as the NCSA one used html like syntaxes which is fine 
if you are dealing with a few simple documents and editing the html by hand. 
Validating the resulting files involves fetching them with a client so that what 
is sent can be checked. This decoupling is not a good idea IMHO. Suppose the 
client is also an HTML editor, which would be handy; it is difficult to put the 
revised document back onto the server.

There is also the overhead of the server having to parse the document to include 
the boilerplate, every time the document is fetched.

I would prefer to see a different solution, whereby each document is complete 
and compliant on the server, which eases maintenence and removes the need for 
per-GET server side parsing. I would rather see a makefile type system that 
holds the dependencies. After you have done some work on your server, just make 
all [and then do a vos release on the . directory in afs ;-) ] 

If files are stored with their includes already included, this requires the
start ands end tags of included sections to be marked in some way. Perhaps 
processing instructions <?included> or something? [Ducks, gets flamed by SGML 
gurus].

Comments solicited.

--
Chris Lilley
+-----------------------------------------------------------------------------+
| Technical Author, ITTI Computer Graphics and Visualisation Training Project |
+-----------------------------------------------------------------------------+
| Computer Graphics Unit,        |  Internet: C.C.Lilley@mcc.ac.uk            |
| Manchester Computing Centre,   |     Janet: C.C.Lilley@uk.ac.mcc            |
| Oxford Road,                   |     Voice: +44 61 275 6045                 |
| Manchester, UK.  M13 9PL       |       Fax: +44 61 275 6040                 |
| X400:  /I=c/S=lilley/O=manchester-computing-centre/PRMD=UK.AC/ADMD= /C=GB/  |
|  <A HREF="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">my page</A>   | 
+-----------------------------------------------------------------------------+