Re: <draft-ietf-iiir-html-01.txt, .ps> to be deleted.
pflynn@curia.ucc.ie (Peter Flynn)
Errors-To: listmaster@www0.cern.ch
Date: Tue, 15 Feb 1994 15:18:21 --100
Message-id: <9402151033.AA15861@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: 1323
> But this shouldn't be a problem because parsing DTDs is about the
> only really easy part of SGML, and building an entity resolution table
> is easy. Having written crude parsers myself in Rexx and C, I have
> a hard time buying the argument that such parsing is a burdensome
> requirement to place on browsers. Surely real-time formatting is a
> much harder problem to solve. Note that there is no requirement that
> a conforming parser be a *validating* parser, nor that it support
> the optional features of OMITTAG, SHORTTAG, and the like.
It's the wall-clock time for the user that's important. OK, some of us
are lucky and work on fast machines: millions of potential users out
there are on dumb terminals on overloaded VAXen, old 386s, Goddess knows
what.
Coming from the other end of the spectrum, real-time formatting is not
that hard either. After all, if you want robust fast formatting, you can
always lift the core code from TeX and use that, shorn of its batch
environment and syntactic dependencies; some systems already have.
> Note that given this requirement, you can cheat a little and refuse
> to parse anything except entity declarations in DTD subsets. In the
I take back what I said about modifying the DTD not being permitted, I
didn't understand fully what was being implied.
///Peter