> Date: Tue, 13 Dec 1994 22:21:31 -0500 (EST)
> From: James C Deikun <jcdst10+@pitt.edu>
>
> The memory footprint for a fully validating SGML parser would be trivially
> greater than that for a simply functional one.
>
> I must disagree. Compare a full SGML parser which supports SUBDOC, LINK,
> a full entity manager, alternate SGML declarations, and arbitrary DTD
> parsing to a parser which employs a pre-parsed DTD with a fixed base
> set, has limited entity support, doesn't support SUBDOC or LINK, etc.,
> and I think you'll find a vast difference in memory footprints. Do the
> numbers.
Didn't they teach you in algebra not to compare apples and oranges?
Didn't you just say in the message I responded to that there was a
tendency to desire more sgml functionality? Yes, a full SGML parser
is more expensive than a lobotomized one-DTD parser, but the latter
doesn't offer "more SGML functionality". A fully validating
lobotomized one-DTD parser would have a memory footprint trivially
greater than a simply functional lobotomized one-DTD parser. A
full validating SGML parser would also be trivially larger than one
that just read in a DTD and fell over dead when the document
instance didn't conform to it. That's why all SGML parsers validate
instead of die; if you've got something that'll parse SGML at all,
having it make sure that what it's reading makes sense becomes
more or less trivial in terms of extra effort.
This point is going to be more or less moot anyway; with the advent
of HTML 3.0 and beyond it looks like a full SGML parser, if not
actually required, would at least represent negligible extra
overhead in comparison with all the other new cruft that will need
to be added.
-- James Deikun (University of Pittsburgh) #include <std_disclaimer.h>