Re: Fate of <P> [Was: Toward Closure on HTML]

"Daniel W. Connolly" <>
Date: Thu, 7 Apr 1994 18:53:31 --100
Message-id: <>
Precedence: bulk
From: "Daniel W. Connolly" <>
To: Multiple recipients of list <>
Subject: Re: Fate of <P> [Was: Toward Closure on HTML] 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1811
In message <>, Dave Raggett writes:
>You are missing the point.

I don't believe so. I believe I have examined the point closely for quite
some time, and I just plain disagree with it.

> My scheme means that people who are
>used to thinking of <P> as a paragraph separator (or terminator
>as the NCSA docs put it) can go on doing so. HTML+ browsers will
>happily deal correctly with such usage. There is NO NEED to
>introduce a new element.

But what the NCSA docs say and what the HTML+ browser does are
different things. Hence the new element. I'd be happy to see an HTML+
browser see:

	Para 1<p>
	Para 2

and infer:

	<pp>Para 1<p></pp>
	<pp>Para 2</pp>

but to infer:

	<p>Para 1</p>
	<p>Para 2</p>

is a bad idea, if you ask me.

>More sophistocated information providers will take advantage
>of the range of features in HTML+ and will be happy too. The
>DTD has been carefully crafted with the help of SGML experts
>with the use of document conversion tools and SGML authoring
>tools in mind.

All this is still possible when the paragraph element is called PP.

> People can continue to author documents using
>simple text editors if they prefer, and the DTD provides a
>means of cleaning up the lack of formality in hand entered

The DTD provides no such thing. The HTML+ extensions to SGML may.

>As for error recovery. The content model is fully exploited
>to infer missing tags. Where this is insufficient, I have
>provided additional comments in the DTD.

I remain unconvinced that those comments constitute a formal
definition of HTML+. But I'm not interested enough to construct a
counter-argument. Mostly, I just think it's silly to say that HTML+ is
"just like SGML except..."