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

• Mail folder: WWW Talk Apr 94-present
• Next message: Danny Padwa: "file: URLs What's the latest sentiment about these things?? I noticed"
• Previous message: Daniel W. Connolly: "Fate of <P> [Was: Toward Closure on HTML]"
• Reply: Roy T. Fielding: "Re: Fate of <P> [Was: Toward Closure on HTML] "

Errors-To: listmaster@www0.cern.ch
Date: Thu, 7 Apr 1994 18:53:31 --100
Message-id: <9404071643.AA21074@ulua.hal.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: connolly@hal.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Daniel W. Connolly" <connolly@hal.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Fate of <P> [Was: Toward Closure on HTML] 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1811

In message <9404071616.AA24721@dragget.hpl.hp.com>, Dave Raggett writes:
>Dan,
>
>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:

	<h1>heading</h1>
	Para 1<p>
	Para 2

and infer:

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

but to infer:

	<h1>heading</h1>
	<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
>documents.

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..."

Dan