Re: <draft-ietf-iiir-html-01.txt, .ps> to be deleted.

pflynn@curia.ucc.ie (Peter Flynn)
Errors-To: listmaster@www0.cern.ch
Date: Wed, 16 Feb 1994 11:01:38 --100
Message-id: <9402160934.AA08795@curia.ucc.ie>
Errors-To: listmaster@www0.cern.ch
Reply-To: pflynn@curia.ucc.ie
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: pflynn@curia.ucc.ie (Peter Flynn)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: <draft-ietf-iiir-html-01.txt, .ps> to be deleted.
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 3075

> 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.

Particularly if it mailed the document owner (<link href> value) each
time the document was accessed, to say it was invalid :-)  Actually,
doing that kind of parsing server-side is a nice idea.

> 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.  

I don't think we can realistically expect to be all things to all people.
At some stage we have to bring the axe down and say "this is what HTML++@
will do, and this is what it will not do". So long as we document clearly
what users cannot expect to do, we will have a stable platform for other
and future developments.

> 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
> their needs.

Consider, perhaps, but they are going to have to learn the facts of life.
Concentration on visual-only documents will kill the whole concept stone
dead. I know they're funders and we may have to kiss the right ass from
time to time, but I don't see why we should compromise the structural
validity of what we are doing just to please some semiliterates in govt
or biz. They want a pictorial network, let them go help Ted Turner.

[wysiwyg editors]
> This is a fundamental issue. I would propose that you cannot reach 
> agreement as to what a good DTD is without 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'm not clear what the issue of WYSIWYG editors has to do with a "good" DTD.
You can use any SGML editor you wish with any DTD, as far as I know.

> 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.

SGML usage is growing very fast, and most people expect it to grow much faster.
I would suspect that a dedicated HTML-only tool would have a very short
lifespan, when people will discover they want to use other DTDs for other
(un-web-related) tasks elsewhere in their work: so they'll want a general-
purpose editor instead.

Having said that, yes, there will be an interim need for simple HTML+
editors which guarantee to produce valid HTML+.

///Peter