Sudden Death (Re: Error handling: yes, I did mean it)
Sarah Slocombe wrote:
> At 10:44 AM 20/04/97 -0700, Tim Bray wrote:
> >To summarize: I proposed that XML processors be required to stop
> >passing data (other than error notifications) to applications after the
> >first violation of well-formedness.
> The concern has been that document information after the first error
> may be of value to the user.
Tim's policy is not a strengthening of XML's well-formedness, but a
discarding of its ability to resynchronise after an error. The ability
to resynchronise, by not having context dependent delimiters or CDATA
and RCDATA declared content types or STAGO in text, was always, to me,
not so much to allow a simpler production rule, but also to allow
robustness, a major fault in SGML. I *really* hope this is not being
A large amount of conversion work is involved in making
imperfect data and markup slightly better.
OmniMark, for example, has become much more useful now as they have
their parser-error recovery: particularly for finding out the scope and
systematic-ness of markup errors. When Omnimark was more 'sudden death',
it could be a pain, and I hope XML doesn't repeat its early
Sudden death goes back to a stream processing mentality. Surely
one of XML's great strengths is that it removes a lot of the
context-dependencies for parsing, and provides
clear resynchonisation points after an error has been found.
Since we have gained the ability to read in a whole document and
resynchronise correctly fairly soon after a markup error, we can
now have editors that let us, Adam Smith-like, address one class of
problem at a time in a document, rather than being forced to address
I know several SGML production houses who would never dream of using
a validating SGML editor, simply because of being forced to work
sequentially, which, for any large or complicated DTDs, puts
demands on markup staff.
So Tim's sudden death proposal sounds good for terminal XML parsers
(perhaps), but it is a real step backwards into 1970's UNIX-style
stream-land. Vendors are the approprite people to decide how their
applications should deal with errors, not us: we shouldn't do anything
that constrains what smarts they can apply.