[Prev][Next][Index][Thread]
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
document
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
inaccessible.
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
Sean Mc Grath
digitome@iol.ie
Digitome Electronic Publishing
http://www.digitome.com