HTML 2.0 Scope [Was: Digest of Tim's mail ]

"Daniel W. Connolly" <connolly@oclc.org>
Date: Tue, 5 Jul 94 15:21:36 EDT
Message-id: <9407051921.AA11265@ulua.hal.com>
Reply-To: html-ig@oclc.org
Originator: html-ig@oclc.org
Sender: html-ig@oclc.org
Precedence: bulk
From: "Daniel W. Connolly" <connolly@oclc.org>
To: Multiple recipients of list <html-ig@oclc.org>
Subject: HTML 2.0 Scope [Was: Digest of Tim's mail ]
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Implementation Group (Private)

In message <9407051525.AA04336@www3.cern.ch>, Tim Berners-Lee writes:
>> From: "Daniel W. Connolly" <connolly@oclc.org>
>
>> I've been wrestling with the idea of reorganizing the HTML document
>> into a normative part and an informative rationale, much like the
>> POSIX 1003.1 document.
>
>There is a good tradition of legally correct but unreadable
>standards.  I don't believe we should follow it.

You can pretty much disregard my proposed document organization. I
decided that I'm not good at writing readable documents, and one of
the writers here at HaL, Karen Muldrow <karen@hal.com> has stepped in
to do an organizational rewrite of the document. She has a lot of
experience with building usable hypertext documentation. See:

	http://www.hal.com/~karen/index.html

I don't know exactly what the organization will be, but I'm confident
that the information will be more consistent and accessible. She expects
to have the rewrite done by the end of July, and we'll mail out sections
as they become available.

>> I've also been playing around with the FrameMaker/DocBook tools that
>> we have here at HaL.  Is anybody out there planning to include this
>> with their docset? 
>
>	"docset"?

I was asking if anybody is planning to include the HTML spec in the
documentation that accompanies their products.



>> Sometimes I'm tempted to take a little bit of the verbiage from the
>> HTML files, stick it in the DTD, and call that the HTML 2.0 spec.
>
>> Then somebody else can write user documentation, tutorials, "how to
>> write a browser" documents, etc. --
>
>ok, but..
>
>>  stick all the stuff about how to
>> compose search URLs from ISMAP documents in there.
>
>That is spec material, not tutorial!  It must be rigorous and defined
>in one unique place.

But must that place be the HTML 2.0 spec? I didn't mean to say that
none of the other documents could be normative.

I guess nobody else sees it this way, but I'll make my case anyway...

I look at a specification as a set of testable assertions. I certainly
want the HTML 2.0 spec to answer questions like:

	True or false: The fragment "<h1>head</h1>text" is a substring
		of some conforming HTML documents
	True or false: The file foo.html is a conforming
		HTML document

But I think it's much more ambitious to compose a spec that defines
answers to questions like:

	True or false: The address http://host/xyz?10,15 is linked
		from the HTML document foo.html. (ISMAP stuff)

	True or false: The HTTP response "...url-encoded...name=val..."
		is a valid response to the HTML form document foo.html.
			(FORM stuff)

	True or false: The postscript document foo.ps is a conforming
		rendering of the HTML document foo.html

And I propose that we put such questions out of scope for the HTML 2.0
specification, and resolve them in future documents. Granted, toward
the goal of disseminating a comprehensive understanding of HTML, this
minimal specification would do little (that's why we put a whole bunch
of informative material in the 2.0 spec). But toward the goal of
collecting all the HTML developments into one framework, this would be
great progress.

I am afraid that if we attempt to specify the random collection of
behaviours currently collected in the HTML spec (before the next major
release of Mosaic when HTML becomes something different altogether),
we will compose yet another WWW spec full of "undecidable
propositions" -- another spec that has lots of interesting stuff, but
imparts no clear understanding of any particular set of testable
assertions.

While this sort of document is useless for many of my own purposes,
and very frustrating for implementors, I get the impression that this
is the sort of document that folks want anyway. Oh well...

Dan