Re: HTML WG Charter: Define Experimental Platform

Paul Prescod (papresco@calum.csclub.uwaterloo.ca)
Tue, 5 Mar 1996 16:44:32 -0500


Date: Tue, 5 Mar 1996 16:44:32 -0500
Message-Id: <199603052144.QAA25868@undergrad.math.uwaterloo.ca>
To: "Daniel W. Connolly" <connolly@beach.w3.org>
From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
Subject: Re: HTML WG Charter: Define Experimental Platform
Cc: html-wg@w3.org, www-html@w3.org

Overall, I like the direction, Dan.  One concern, though.

At 01:04 PM 3/5/96 -0500, you wrote:
>Rather than binding text/html to any particular DTD, we define it to be and
>SGML document type that includes HTML level 1, as defined by [RFC1866]. (An
>SGML document type t1 includes t2 if every document conforming to t2 also
>conforms to t1.)

Is the definition of text/html too broad?  It seems to me that we are
actually defining text/sgml-with-html-wrapper.

Any SGML DTD can be trivially modified so that it "includes" HTML, through a
small wrapper:

<!-- Wrapper to allow me to disguise TEI.5 documents as HTML -->

<!ENTITY % html.content "HEAD?, BODY?, TEI.5?">
<!ENTITY % html PUBLIC "-//IETF//DTD HTML 2.0//EN">
%html;

...<!-- And a bunch of TEI.5 element definitions --?

Now my DTD "includes" HTML 1.0 (according to the definition in the RFC), but
many documents that conform to my DTD don't look anything like HTML at all:

<HTML>
<TEI.5>
a bunch of TEI.5 content
</TEI.5>
</HTML>

This (valid) text/html document doesn't even have a <TITLE>!

I can think of a few ways to deal with this:

#1. Specify the important HTML elements and idioms like HEAD, TITLE, BODY
and A, and define _exactly_ what can and can't be added and removed from
HTML dialects.  In this vision, HTML becomes either some form of
architecture or just an standardized set of tags that can be thrown into any
DTD as long as they are used in standardized ways.

#2. Forget HTML dialects, move directly to SGML and figure out how to
preserve all of the HTML idioms through style sheets (a la Panorama),
standardized element names (a la CALS tables), a mapping from element names
to attributes (ICADD), processing instructions (Panorama again) or something
else.

#3. Keep text/html fixed and standardize a framework for experimentation in
text/x-html.

#4. Ignore this problem and depend on "the market" to force people to
conform to HTML elements and HTML idioms for proper display on conventional
browsers.  As style sheets emerge and improve, text/html evolves towards
text/sgml and at some later date we remove the requirement to include the
HTML dtd.

Fine, but if the text/html document type has no real teeth to enforce
HTMLish-ness, why not remove the requirement? Sure, user agents still have
to include the HTML 2.0 DTD, but document authors shouldn't have to.

 Paul Prescod