> 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: [email protected] | | Manchester Computing Centre, | Janet: [email protected] | | 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> | +-----------------------------------------------------------------------------+