Lists Home |
Date Index |
- From: email@example.com
- To: firstname.lastname@example.org
- Date: 30 Nov 99 11:39:49 -0500
> >So as it stands, there will exist valid SML documents that are not well
> >formed XML and will therefore trigger a fatal error if given to an XML
> I was talking about removing an error reporting requirement
> because I believe XML WG went overboard with the error
> reporting requirements which places a heavy burden on
> the performance of XML parsers.
In other words, the WG went overboard in specifying that when something is broken,
the parser must say so? I don't consider that overboard at all.
> IMHO, HTML crowd got burnt badly with HTML's forgivable parsers
> and over-reacted. There are other ways to solve this sort of
> problems without resorting to high tariff on all.
I think the UA authors finally got sick of having to code bloated "forgiving" parsers
because the HTML spec required a huge amount of tolerance, but I could be wrong.
After all, this is touchy-feely 1999, where getting the right answer to 1+1 is not as
important as how you FEEL about the answer you got. Am I the only programmer left
who *likes* getting syntax errors that stop your production cold, because they give you
an error you can fix quickly instead of a problem you may not even notice until it's too
Way back in the Dark Ages of my computer education, my first real computer science
teacher told me something very valuable. There are three sorts of errors in
programming, each more serious than the last. The first is a syntax error, and I love
getting those - because they tell you exactly where the problem is and what's wrong.
The compiler is supposed to halt compilation on those, because the output is going to be
garbage anyway. ("It's broke, so get it fixed.") The second type is a run-time error - all
the syntax looks right, but something critical breaks when the program runs. (See GPF,
memory allocation errors, etc.) Here again, you get an error message, so you at least
know what the problem is. If you're lucky (or thought ahead), you even get some
information that helps you track it down. The third and most serious error is the logic
error - where the program runs smoothly, but the results are incorrect. (For instance,
running a photo of a tree through a rendering system and getting an antelope.) The
syntax is right, the resources are cool, but your algorithm is screwed up...and *that's*
what you have to figure out on your own.
These stringent error-reporting requirements that you complain about are syntax errors,
sometimes run-time errors - and the WG is quite correct in requiring the parser to kick
nonconforming documents out instead of trying to figure out what they meant to say. If
it's broken at that basic a level, it doesn't need to be set loose - make the author fix the
errors first. (And if it's program-generated code, that's an even better reason for this
requirement - the error will show up in a log, and that lets the software author know
there's a problem.)
Syntax errors are easy to fix if reported, but they can be damned near impossible to find
with a mushy parser that lets 'em slide through. All a tolerant parser does is consume
CPU cycles and encourage sloppy coding - and neither of those does anybody any good.
(Well, okay, maybe Intel and AMD benefit...but that's about all.) The way to fix sloppy
code is not to tolerate it. Sure, utilities like HTML Tidy which will fix existing
documents are nice - but odds are, without a strong push towards intolerance, it never
would have attained its current level of prominence.
Rev. Robert L. Hood | http://rev-bob.gotc.com/
Get Off The Cross! | http://www.gotc.com/
Download NeoPlanet at http://www.neoplanet.com
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)