Re: Toward Closure on HTML

Jim Davis <davis@DRI.cornell.edu>
Errors-To: listmaster@www0.cern.ch
Date: Tue, 5 Apr 1994 19:11:49 --100
Message-id: <199404051706.AA09487@willow.tc.cornell.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: davis@DRI.cornell.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Jim Davis <davis@DRI.cornell.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Toward Closure on HTML
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2743

Prologue: It would be better if people refrained from flaming
and ad-hominum attacks.  I don't agree with everything
Dan proposes but he's trying to do the right thing and
people should show real reasons for their objections, and
treat his ideas with respect.

Now here are mine:

1) clarifying question: Dan do you assume that in the future
people will not write directly in HTML using text editors, but
rather will write in other languages that get translated to
HTML or will be using fancy editors that generate the HTML
for you?  
  => If so, and if he's right, then this changes the language
design.  The key issues become making HTML expressive and easily
parsed.  So this is the fundamental assumption we should debate.

  => How widely available *are* these tools?  Are we talking Microsoft
Word here, or the SGMLs tools?

2) including explicit DOCTYPE is a good idea.

3) I can see no benefit whatsoever to making an incompatible change
to the anchor syntax.  But this depends in a major way on the
key Assumption (#1 above).  Here's why:
  it is a terrible idea to have anchors  stored inline in the text. 
     The reason is that to add an anchor to a document, you must have
     write permission on the document.  Thus inline anchors prevent me
     from linking to or from anything I dont own.  The Hyper-G people
     make this argument well.
   Inline anchors are okay if HTML is only used as a transmission standard,
   and not as a permanent storage standard.  We can store the anchors 
   separately, and add them in when the document is send across the net.

  but if people end up writing "naked" HTML, then they will have inline
  anchors permanently in the text.  if they use tools, then *maybe* the
  anchors can be stored external.  And if they use tools, then nobody
  sees raw HTML.

4) There is a large demand from the user community for inline tables
and images.  If HTML does not provide these, people will stop using HTML.
(I do not know how much demand there is for inline math)

5) as for the claim that forms should be a separate DTD - I don't see
the benefit.  HTML with forms is rapidly becoming a powerful way to
implement application interfaces.  there is a big demand for this feature.
Indeed, I expect it to grow - The current forms behavior is a step
towards fully programmable clients, and we may go that direction.  When
HTML is used in this way, it becomes something different from SGML +
hyperlinks.  You argue that you can't print a form, well so much the
worse for printing.  Eventually hypermedia has to become something
BETTER than mere paper, better than paper with cross-links.  it is
folly to remove working features from the language just because they
run only on silicon, not cellulose.