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.
<SoapBox>
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
DTDs.
</SoapBox>
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