>
> Date: Tue, 13 Dec 1994 11:28:48 +0100
> From: Dave Raggett <dsr@hplb.hpl.hp.com>
>
> This argument is nonsense. Arena is able to detect markup errors trivially,
> and the real (but not very hard) work is in being able to recover from
> errors.
>
> Tell me Dave, what is the memory footprint for a fully validating SGML
> parser on a Windows 3.1 platform; what performance penalty will be paid
> on a 386/25Mhz Windows machine for doing a full validation prior to
> displaying a document?
Well, I'm not Dave, but...
The memory footprint for a fully validating SGML parser would be trivially
greater than that for a simply functional one. In fact, a validating
parser will be required in any case. No need for sophisticated error
detection, but if the parser doesn't do SOMETHING to handle invalid data
it will be terribly unstable.
> than error detection, then you are certainly correct. However, given
> the trend towards including more SGML functionality, it will be hard
> to maintain in a small profile -- soon you will end up with a full
> SGML parser.
Since a full SGML parser is the only way to provide full SGML
functionality, one would suppose so. This has less to do with the
client doing validation than it does with the trend you've noticed
toward more SGML features.
Adaptive compensation on the order of Mosaic, by the way, would be
much more of a burden, besides being a much worse idea.
> I still think that servers should validate their documents prior to
> transmitting them, thus relieving browsers of the burden [of course
> some minimal error detection recover will still be necessary in the
> browser, but not full validation capabilities.]
Yes, server validation would be nice; it would help protect people
somewhat from the vagaries of their own browsers.
-- James Deikun (University of Pittsburgh) #include <std_disclaimer.h>