Date: Thu, 20 Jul 1995 00:50:48 -0400 From: Ka-Ping Yee <email@example.com> Subject: Re: In-line HTML files? To: Keith Rogers <firstname.lastname@example.org> Cc: email@example.com In-Reply-To: <9507200141.AA07333@isis.sp.isl.secom.co.jp> Message-Id: <Pine.3.87.9507200048.A11917firstname.lastname@example.org> On Wed, 19 Jul 1995, Keith Rogers wrote: > > All of the responses I have received for this have indicated methods by which > a file on the *same machine* can be included. What I actually had in mind was > that the file to be included would be on a *remote machine*. Is there any way > to do this? My impression is that the server-side includes will not cover > this functionality. Of course, since no one has told me where I can get > documentation describing server side includes, I may be mistaken. Yes: all the implementations of server-side includes that i know of will include files only located on the same server. To reference files on other servers would not be impossible -- it's just that if we're going to do it, we might as well properly hash out a way to reference it in HTML instead of doing hacks to be parsed by http daemons. The problem with including arbitrary bits of HTML is that you have no guarantee other documents will be conforming documents. In fact, it would not be possible to directly include another conforming document (with another <head> and <body>) within a conforming document. Even two fragments of correct HTML can cause havoc when one is included within the other (to wit, imagine nested <A>s or <FIG>s). This is why i believe included documents should be treated in a similar fashion as figures: they are set apart in their own box (that is, logically speaking -- the box doesn't have to be physically visible) and continue to be treated as separate documents. I mentioned this while attempting to open a more general discussion about different presentation methods (see http://www.acl.lanl.gov/HTML_WG/html-wg-95q2.messages/1230.html). > In this context, <IMG> and <FIG> are merely ways of specifying that the > media be somehow *embedded* into the document when it is presented; as > concerns this <INCLUDE> idea, for instance, there is no reason why > "text/html" can't be the "Content-Type:" of a <FIG>. > > If i could digress for a moment on <INCLUDE>: i agree that the > ability to include referenced HTML is certainly needed and very useful. > But i don't really see that a new tag needs to be created. There's a > problem with *directly* inserting HTML source into a document, because > there's no way to guarantee that the syntax will remain correct (stick > a <BOLD> in the middle of a document, and you screw up the entire rest > of the document). Furthermore, what happens when included subdocuments > have their own style sheets? This is why it makes sense for an included > HTML subdocument to be displayed off in its own area (like a figure box), > where it cannot directly affect the main document. > > So, i propose a more general approach to presentation of referenced > resources. As i see it, there are four presentation/retrieval > methods, only two of which we use extensively at the moment. [...] Ping (Ka-Ping Yee): 2B Computer Engineering, University of Waterloo, Canada email@example.com | 62A Churchill St, Waterloo N2L 2X2, 519 886-3947 CWSF 89, 90, 92; LIYSF 90, 91; Shad Valley 92; DOE 93; IMO 91, 93; ACMIPC 94 :: Skuld :: Tendou Akane :: Belldandy :: Ayukawa Madoka :: Hayakawa Moemi :: New! <http://csclub.uwaterloo.ca/u/kryee/> Yeah, i finally made a home page.