Re: <draft-ietf-iiir-html-01.txt, .ps> to be deleted. Dave Hollander <email@example.com>
Date: Tue, 15 Feb 1994 22:41:05 --100
From: Dave Hollander <firstname.lastname@example.org>
To: Multiple recipients of list <email@example.com>
Subject: Re: <draft-ietf-iiir-html-01.txt, .ps> to be deleted.
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
> = Peter Flynn
> > > = Dave Raggett
> Q. By "parse" do we mean "check for conformance and reject if in error"
> as well as "extract anything which needs acting upon". The whole area
> of what a browser should do when it encounters invalid HTML+ needs some
> more thought.
One opinion: browsers should be as robust as possible; however, to
help people make the document truly portable, there should also be
a validating parser tool available, perhaps built into the servers.
> Because a large amount of what people may want to put up on web servers
> is not necessarily technical documentation. This is why we went to the
> trouble of bringing together the TEI and some browser writers. Using
> DocBook would be _way_ too limiting.
Indeed. For something like the web, I can not think of any semantic domain
for a tag set, except display semantics, that is not limiting. For example,
I am looking into commercial use of the internet and this would be all
sorts of non-hierarchy stuff. Any D1...Dn based structure will be in the
way (but, allowing for tag abuse, ways to do it can be found).
Likewise, I am concerned about the expressiveness of HTML+. There are
many document types today that can not be reproduced faithfully using
this specification; interactive catalogs, technical magazines are two
examples that will not be able to be done without significant compromise
to their design specifications.
Many of those who will be funding the growth of the Internet (and other
networks) will be looking to reproduce their information in the visual
form they are used to. IF we wish this to be a tool used (and thereby
moved forward by) these types of applications then we need to consider
> > >In future, we expect authors will use specialized wysiwyg editors for
> > >HTML+ or automated document format conversion tools and hence produce
> > >documents which naturally conform to the DTD.
> Don't even have to be WYSIWYG...but they will need to be conformant.
This is a fundamental issue. I would propose that you can not reach
agreement as to what a good DTD is with out agreeing to this aspect of
it usage. So, what will it be?
____ Full support for hand tagging
____ Limited support for hand tagging, limited support for specialized editor
____ specialized editor or tool
I assume that we should support hand tagging as much as possible up to the
point where "real" SGML tools can support, but not beyond! However, there
may be a way to get the tools community to provide specialized tools
customized for HTML+ at little or no cost. This is such an attractive idea
that we should consider it.