Re: Error handling in XML

Peter Murray-Rust wrote:
>         "XML is great because you can't send people broken documents"

Um. Yes you can. I think the more accurate paraphrase of Tim's proposal
is: "XML is great because you can send people broken documents but they
are guaranteed not to be able to read them, if their user agent has
followed the specification to the absolute letter of the law." (which I
believe to be unlikely) 

Let me address a related point that has been brought up a few times:

> 3. XML will be used to support EDI, big-time.  The OFX format behind
>    Money/Quicken is about to become XML, it seems.  Obviously, a 
>    violation in this case will/should/must lead to instant abort of
>    the transaction.

> I wouldn't 
> want my medical records to rely on HTML, nor would I want the 
> aircraft maintenance manual for any plane I might be in to be broken 
> - how can you trust the processing of a document that is broken?

This proposal does nothing to improve the robustness of any particular
XML system. Each system has the *choice* of whether to continue
processing the data or discard it after the first error. Taking away
that choice will not improve the robustness of, say, a financial
services application or chemical modeller. Are financial services or
medical software developers not intelligent enough to make their own
decisions about their robustness contraints? And how far along the
reliability path does well-formedness get them anyhow? What about the
reliable encoding of numerics? What about structural validity? What
about broken hyperlinks?

Or to put it another way: I absolutely WOULD trust a financial services
app that ran on top of HTML as much as one that ran on top of XML
because the HTML or XML produced would NOT be the same as appears on Joe
and Jane homepage's website. It would presumably be thoroughly validated
at both ends, including checks that XML does not even specify, such as
"is this date is ISO xxx format?" So who cares what the XML spec says
about it? They will roll their own error recover system which may or may
not be compatible with that described in the spec. These people had
better already understand robust transactions and how to achieve them or
we are all in deep dodo.

Let me reiterate that I am in favour of requiring the processor to
signal the user when there is an error. That's all that is needed to
avoid the HTML mess. I am not in favour of tieing people's hands in
choosing how to recover from errors.

 Paul Prescod