Re: In-line HTML files?

Paul Prescod (papresco@calum.csclub.uwaterloo.ca)
Thu, 20 Jul 1995 14:38:32 -0400


Date: Thu, 20 Jul 1995 14:38:32 -0400
Message-Id: <199507201838.OAA26109@calum.csclub.uwaterloo.ca>
To: Ka-Ping Yee <kryee@novice.uwaterloo.ca>,
From: papresco@calum.csclub.uwaterloo.ca (Paul Prescod)
Subject: Re: In-line HTML files?
Cc: www-html@www10.w3.org

At 01:03 PM 7/20/95 -0400, Ka-Ping Yee wrote:
>On Thu, 20 Jul 1995, Paul Prescod wrote:
>> You are suggesting a mechanism for implementing full subdocuments.  I am
>> suggesting a mechanism for implementing document fragments.  Both are
>> necessary.  
>
>I agree -- it's just that document fragments seem to be the trickier of
>the two.  

I tend to see yours as trickier.  Can the subdocument have a new BODY with
new background and everything?  A new style sheet?  Is there a sbudocument
stack?

>How do you define the "document type" of a fragment?  Only when
>you have enumerated and defined all of the possible document types
>(that is, state-based assumptions) that a fragment can be can you declare
>just where and how that fragment is allowed to be used.

Think of #include.  If #include includes data that doesn't "jive" with the
data around it you get an error message.  This is the same.  If it creates
an incorrect document, the user alerts the page designer and they wrangle
with the fragment owner, just as it would be if I server-side included some
text in someone else's home directory that I did not have writes to modify.

>Okay.  So what is "fragment.html"?  It can't be HTML; is it some sort of
>subset, like %text; ?

It is HTML, but not a full, correct HTML document, if you see what I mean.
Just a bunch of HTML that is pasted into the parent document and then validated.

>It isn't different.  But it is still a possible source of great frustration,
>because most authors and users will probably not want to take the time to
>learn the structure of the HTML DTD, and instead simply go including bits
>and pieces of HTML all over the place.  Including complete subdocuments is
>a little bit "safer" in that the scope of inclusion is fixed.

You are right.  It is a powerful tool that can be misused.  

>Would you allow things like including "foo.html" where "foo.html" contains
>
></ul><h2>Awooga
>
>?  There's no telling what might happen.

The same thing that would happen if you server-included that data.

>I've seen enough garbage all over the Web, with multiple <title>s, <body>s,
>and misplaced tags (see <URL:http://www.msn.com/explore.html> for a <head>
>within a <body>).  Or see <URL:http://www.aist.go.jp/htbin/wclk> for a 
>rather unusual document that looks like it was produced by inclusion.

Point well taken.
  
>Perhaps.  But complete subdocument inclusion is also safer in that it makes
>absolutely clear the attribution of each component.  Snagging a document
>fragment and inserting it into one's own smacks just a bit of plagiarism
>(i *know* the Web is about copying information all over the place, but this
>behaviour would further blur the boundaries of possession).

If I want to steal from someone cut and paste is a much more subtle,
harder-to-trace mechanism than sending user's browsers out getting document
fragments from his site.  Besides, you had suggested that the subdocument
mechanism might be "invisible" (no box).

>As you said, both mechanisms are probably necessary.  But including a
>complete subdocument is likely to cause less confusion while accomplishing
>what most people seem to want (disclaimers, copyrights, signatures, etc.),
>so i think it would be better to make it the first of the two objectives.

It seems harder to implement to me.  The code to implement entities is
aleady freely available.

>> HTML Myths Page: http://www.incontext.ca/~papresco/htmlmyth
>
>I was looking forward to seeing this, but it wasn't available when i tried
>it.  Is this document up yet?

That signature file got out by accident.  Apologies to those that tried to
acces it.  The real URL is:

http://www.undergrad.math.uwaterloo.ca/~papresco/htmlmyth/htmlmyth.html

It is still under development but usable already.  Feel free to cut and
paste parts of it where appropriate.

 Paul Prescod

----------------------------------------------------------
Paul Prescod (papresco@calum.uwaterloo.ca)