Tim Berners-Lee (Peter and 822ext recipients who don't know, Tim is the
co-ordinator and main force behind the WWW effort) writes on Mon, 06 Sep
1993 10:04:56 +0200:
I seem to have missed this thread up to your message of
Fri, 03 Sep 1993 12:28:34 -0400 (EDT) so i'd be interested to
know the original distribution. Perhasp I am missing from a list.
Proposed alternate main principle: Any time one designs something
that can be extended, it is necessary to be extremely clear about
what an "old" processor should do when it encounters an
unrecognized extension.
The HTML spec always intended that unknown tags or attributes
should be ignored, in the sense that the parser should behave as
though the TAG were not there, and process the content of the
element as though it had been content of the containing element.
This is also specified for HTML+.
This means that the client which says it accepts HTML means that it
wil accept HTMLL with unknown junk which it will ignore. If a server
requires understanding of new tags, then the server has to invent a
suitable name for the new Content-Type and can't serve it as HTML.
Clients understanding the new type mention that in the HTTP
request, and so get it.
Which is the behaviour one wants of course.
I don't see any value in saying "This is _kinda_ like HTML but if
you treat it as HTML you'll screw up". So I don't see much value in
allowing a form of tag for "incompatible extenstions". I agree
that having a way of distinguishing "safe to discard element"
would have been useful. Like -- what, tags beginning with "Z"?
It would have to be a rapid retrofit!
Tim Berners-Lee
Tim,
The original note, which might be described as "new versions considered
harmful" was posted to the ACM Risks forum (mailing list and newsgroup).
That was followed by the posting of a copy to ietf-822 (the MIME list)
as a cautionary note about some of the things that are being proposed
with Nathaniel's "text/enhanced" (formerly "richtext") proposal. I
didn't assume that you had a problem, only that you should be aware that
the discussion had come up.
The problem that stimulated the note apparently involved a client that
discarded an element, rather than the associated tags. From your
description, such a client is broken. Having not looked at the HTML
definition language recently, that might have resulted from hasty
reading, but that --and just sloppy program-writing-- are "risks" as
much as bad definition.
Seems to me that the value of defining an "incompatible extensions"
model arises if one wants "version N" systems to be able to accept
"version N+1" files. That is a design decision, one way or the other.
But, if the answer is "no, don't even try to guess", it seems to me that
must be very clear. In the particular case cited, the contention was
that you shifted to "version 2" without any explanation or warning as a
consequence of subsuming SGML. We would all agree that such shifts are
a bad idea, but apparently some client-writers didn't get the message,
which is a problem, somewhere.
john