Message-Id: <199607102210.PAA21069@web1.calweb.com> Subject: Re: Parsing methods To: email@example.com Date: Wed, 10 Jul 1996 15:10:10 -0700 (PDT) From: "Lee Daniel Crocker" <firstname.lastname@example.org> In-Reply-To: <m0ue75o-0002URC@beach.w3.org> from "Daniel W. Connolly" at Jul 10, 96 05:46:44 pm > >IE: should the parser see > > <hello%^ myname=foo> > >as a TAG that was messed up........ > > OR > >as plain text? > > > >i say as a messed up tag..... > > And you'd be right. > > If you want to be sure, check with a validating SGML parser. As much as I would like to see producers use validation, and as useful as general-purpose SGML is to unambiguous communication of structured information, I must express a fundamental disagreement with Dan and some other SGML-heads on how to handle "invalid" SGML. I think that human-written text-based format like SGML _should not have erors_, period. I.e., the language should be a way to interpret whatever the hell the writer throws at you. If it is clear and unambiguous HTML, great--interpret it that way and go on. If not, I believe a reader should try to be flexible, and in most cases, just print questionable markup as is. It is far more useful for a reader to see something like &emdas; on his screen when the author meant &emdash; than to see some meaningless error. And for a parser to throw up its hands and refuse to parse <.. width=50%> rather than have some rules for dealing with markup like this. If that means two separate sets of rules for readers and writers, then sobeit.