Re: Error handling in XML

[Peter Flynn re stopping after first error]

>It is absolutely the "right" thing to do, because plowing onwards after
>a syntax error will likely just throw up another few thou "errors". I'm
>just worried it's not going to wash with the people who have to market the
>product (any marketeers out there?). 

I do not think there is any hope that the Big M or the Big N are going to
insist on well formedness.
The mass market want ease of use above all else. Joe User wants the software 
to just get on with it - whether it makes any logical sense or not. This is
a fact of life 
and s/w that goes with this flow sells by the truck load. A lot of comes
from Seattle :-)

Case in point:fire up a modern, Excellent spreadsheet and create two rows of
cells like this:-

23                     12/2/93
Bannana           $14.44

Draw a few graphs of that data. See what I mean?

>[It's really a weird phenomenon: no-one expects a C compiler to gracefully
>accept syntax errors, put them right as it sees fit, and carry on compiling.
>But everyone expects a Web browser to handle HTML like N and M. Anyone
>investigating the psychology of this?]

I do not think the comparison is a valid one. Programming languages that barf on
a syntax error do so because a partial executable image is a useless thing.
A partial
document is *not* a useless thing. One of the cool things about XML as a
format is that some of the content can be recovered even in the face of
error. Compare this
to our binary document friends where a blown byte can render the entire content

As I said in a previous post, I can think of a number of useful apps that
can work sensibly
with broken XML. I think the problem with M and N is that there is no way to
say "warnings = high"
and get told about WF problems.


Sean Mc Grath
Digitome Electronic Publishing

Received on Saturday, 19 April 1997 10:31:48 UTC