W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > April 1997

Re: Error handling: yes, I did mean it

From: Joe English <jenglish@crl.com>
Date: Mon, 21 Apr 1997 12:11:20 -0700
Message-Id: <199704211911.AA15753@mail.crl.com>
To: w3c-sgml-wg@w3.org

Tim Bray <tbray@textuality.com> 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.

This proposal does sound appealing, but I agree with the others
that it's too draconian.

Here's what I would like to see as a requirement:

	1. An XML parser _must_ report the first error it detects
	to the application, as soon as the error is detected.

	2. XML user agents _should_ notify the user of any errors
	encountered in an XML document.


[ By "parser" I mean a chunk of code which translates XML into
  another form suitable for manipulation by some other chunk of
  code; the "application" is the other chunk of code which does
  the actual processing.  By "user agent" I mean an application
  that renders XML in a form suitable for human consumption. ]


Requirement (1) is similar to the "C" flag that SGMLS (fails to)
generate at the end of a (non)conforming document, except that
it would be reported earlier.  This would leave it up to the
application to decide what to do with bad XML.  Mission-critical
applications (like financial transactions) and applications that
are highly sensitive to correct input (like XML-LINK) could
decide to stop processing immediately, while things like display
engines could plow ahead.

As for requirement (2): most HTML is deemed correct by its
creators if it passes the "looks good in Netscape" test.
A blinking red light in the status bar saying "Bad XML"
would go a long way towards preventing ill-formed documents
from ever being published; no matter how good the error recovery
in the display engine is, that blinking red light would make
bad documents fail the "looks good" test.


Of course, as with Terry's proposal, parsers would be free
to report as many errors in as much detail as they like;
that's a quality-of-implementation issue.  The main point
is that parsers must inform applications, and applications
should inform users, if the input is no good.



--Joe English

  jenglish@crl.com
Received on Monday, 21 April 1997 15:13:31 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 10:04:25 EDT