Re: Reality Check for HTML 2 RFC

"Daniel W. Connolly" <connolly@hal.com>
Date: Wed, 5 Oct 94 14:07:38 EDT
Message-id: <9410051806.AA00230@ulua.hal.com>
Reply-To: connolly@hal.com
Originator: html-wg@oclc.org
Sender: html-wg@oclc.org
Precedence: bulk
From: "Daniel W. Connolly" <connolly@hal.com>
To: Multiple recipients of list <html-wg@oclc.org>
Subject: Re: Reality Check for HTML 2 RFC 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)

In message <9410051741.AA14242@hook.spyglass.com>, Eric W. Sink writes:
>
>We've been focusing our attention in this area on getting this spec
>done and out as an RFC.  As we look at the document, it is apparent
>that there is valuable material there which does not necessarily
>need to be part of the RFC itself.

Ahh... another minimalist engineer like myself.

>  We've been thinking of omitting
>the overview section plus the DTD reference from the RFC.

Hmmm... I've had several folks comment that the DTD reference is more
useful than the DTD itself. I don't think I'd feel comfortable omitting
the DTD reference.

And for another class of audience, the overview is the only part of
the document they need. I'd hate to see it go.

>  This would
>greatly shorten the actual RFC by removing essentially redundant
>material.

Yes... but would the resulting document be more or less useful?  It
would be a shame to do all this work and fail to communicate the
results effectively.

What about releasing 3 RFCs: one "normative" and 2 "informative" and
perhaps released slightly after the normative one?

>  The DTD references are auto-generated and have some problems
>which Dan has mentioned before.

Those problems are addressed somewhat in the $Id: html-pubtext.html,v
1.1 1994/09/23 22:49:26 connolly Exp $ release of the DTD materials.

>  The overview is almost user-level material
>and contains fancy formatting which is hard to reproduce faithfully
>within the standard RFC format guidelines.
>
>These parts of the document would certainly still appear in a pretty-printed
>version where this kind of useful user-level material is more appropriate.

Hmmm... as I understand it, the RFC editor makes a judgement about
whether a postscript version of an RFC is "the same" as the plain text
version. I bet they'd balk at this.

Besides: I'd hate to see the "guts" of the document distributed to
folks that look at it and say "I don't get it. SGML is inscrutable."
There's a danger in separating the informative parts from the
normative parts that we should consider carefully.

Dan