WWW Support Questions

"Daniel W. Connolly" <connolly@hal.com>
Errors-To: listmaster@www0.cern.ch
Date: Thu, 5 May 1994 19:23:32 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9405051710.AA25303@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: WWW Support Questions
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

I didn't mean to dismiss Mr. Clausnitzer's question altogether...
it appears that he has done his homework and is willing to contribute.
What I took for whining was really just broken English. I apologize.

I guess I'm just frustrated by the overwhelming demand for information
about WWW.


	But what REALLY frustrates me is that had we taken a more
	formal approach to designing WWW technology, many of these
	support issues would have been avoided.

	Unclear specifications lead to conflicting implementations
	which lead to confusing behaviour which leads to
	(1) zillioins of support questions,
	(3) lack of confidence in the technology, and
	(2) high cost of development and maintenance,
		due to the need to support past hacks and kludges

	When developing a new technology, one cannot expect to
	"get it right the first time," but there is no excuse
	for not investigating the existing body of relavent
	knowledge and applying it consistently.

	There is no excuse for not studying SGML before making
	modifications to HTML. I understand that SGML is obscure
	and the standard is nearly impenetrable. There is no
	excuse for that either, but what's done is done. There
	are other documents describing SGML. There is the excellent
	sgmls tool from James Clark. There is comp.text.sgml.

	HTML _is_ an application of SGML. Get used to it. There are
	costs involved: HTML is, because of this, inherently somewhat
	complex. But there are benefits as well, and from my
	experience, they outweigh the costs.
	When the HTTP developers embraced MIME and the technology
	framework of previous TCP-based protocols, (NNTP, FTP, SMTP),
	they became much more productive. They are able to experiment
	with a clear idea of which techniques are likely to conflict,
	and which techniques are independent, i.e. which techniques
	must be part of the common framework (the protocol) and which
	techniques can be left implementation-dependent.

	But I think some of the principals of MIME have been
	missaplied. The format for HTTP messages is called "www/mime"
	when it uses the syntax of the MIME "message/*" types.
	Why not "message/www" or "message/http"? This is not just
	an issues of the spelling of a name. It's a question
	of understanding the essential techniques of MIME.

	And the URL/URI/URN/UR* technology is not doing so well. URLs
	are a defacto standard. But, for example, witness the
	current confusion about file: versus ftp: versus local:
	The MIME external body access-type technique was developed
	several years ago. We should have adopted their names,
	and gone with ftp:, anon-ftp:, and local-file: a long time
	ago. The research behind WAIS doc-ids is also relavent,
	and I think we are missing some of its crucial components
	(copyright status and original-id).

	And if we are to evolve HTML technology from its current
	very-useful-but-far-from-sufficient state, we MUST apply
	more formal methods to abstract the essential techinques
	from the various applications. I suggest we take a serious
	look at the architectural-form techniques from the HyTime
	standard development, and develop (1) a set of WWW
	architectural forms for linking and navigation, and
	(2) a stylesheet mechanism so that the WWW linking and
	navigation techniques can be applied to a variety of SGML

Whew! I needed that!

Daniel W. Connolly        "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project   (512) 834-9962 x5010
<connolly@hal.com>                   http://www.hal.com/%7Econnolly/index.html