Hot Metal and HTML
weibel@ora (Stu Weibel)
Date: Mon, 13 Jun 1994 13:35:56 +0500
From: weibel@ora (Stu Weibel)
Message-id: <9406131735.AA03342@ws02-00>
To: html-ig@fssun09
Subject: Hot Metal and HTML
X-Sun-Charset: US-ASCII
Content-Length: 3015
Tim asked me to forward the following to the html-ig list while we are
straightening out the subscription list.
stu
---------------------------------------------------------------------------
Dan,
I hear that Hot Metal won't read HTML.
I want to reiterate what I feel are
the boundary conditions on anything being called HTML.
In HTML <P> has been defined and used as a separator rather than a container.
There are many who would have prefered that it had always been a container,
but there it is: it isn't.
The essential thing which defines the boundary on changes to the HTML DTD
is network interoperatbility. That is a sine qua non. That is, if a
document is valid HTML according to spec n, and it sent across the
net as text/html, and it is parsed by a parser of any version m of HTML
where m>n, it must parse OK. If not, HTML will go the way of rtf and
postscript, with the reputation that you can interchange it but never
tell in advance whwther it will be worth it. It is *not* worth going
this route even if you think that you are cleaning things up, etc.
Now I am happy to see, in order to help us make changes we want to make,
that the specification of HTML can go futher than SGM DTD. For example,
text/html already specifies that the document should match the DTD *and* also
it should not contain any new declarations of entities etc etc.
Similarly we can insis onthe nehaviour of browsers meeting tags they
don't recognise. We need to do thing like this, because SGML has been
designed as a top-down once-only design and not for stepwise refinement.
In fact, it is easy to define when a program (sgmls aside) should
infer a <p>. So I'd like to know whether we are limited by SGML or
sgmls.
Dan has tried to show how we can move to containers for P, DT, and
still call it HTML. Someone somewhere is wrong, as HoT MetaL
WON'T READ HTML and WON'T WRITE HTML.
Either Hot metal is not implying tags as it ought, or Dan's scheme doesn't
work in theory. Which is it?
* If the scheme doesn't work in theory, we scrap the containers for HTML,
and call everything with P as containers HTML+ which is incompatible,
and define text/htmlplus. That's fine... a single jump to get things clean.
* If the scheme does work in theory, then HotMetal can be fixed to imply tags
on input. In fact it would be better for interworking for it to
mimimise them away on output too: otherwise it relies on the rule of
browsers ignoring unexpected tags.
Which is it? I am not having HTML go the way of RTF and postscript,
that one never knows what will interwork with what. If you screw
it up once with HTML then noone will ever trust it again.
Much though I have longed for sometig like Hot Metal to arrive, and really
appreciate Uri maing it available, if it works against interoperability it
must give up any claim to supporting HTML as well as the (rather cute, I
like it) name.
I send this to this list only (the HTML *Interopability* group)
now so that we can clear it up.
Tim