W3C home > Mailing lists > Public > xml-editor@w3.org > October to December 1998

"error" reporting and recoverability

From: David Brownell <db@Eng.Sun.COM>
Date: Wed, 02 Dec 1998 14:12:46 -0800
Message-ID: <3665BB5E.9A1A11FB@eng.sun.com>
To: xml-editor@w3.org
I've noticed when testing against the spec that the definition of
an "error" in section 1 is particularly useless when it comes to
defining common behaviors:

	Error:  a violation of the rules of this specification;
	results are undefined.  Conforming software may detect
	and report an error and may recover from it.

The problem is that this definition promotes wide variations in
handling errors:  it permits parsers either to ignore the "error"
entirely, or to treat it as a fatal error.

Minimally, I'd suggest that this be tightened to require error
reporting "at user option" (as for validity errors).

It'd also be advantageous to preclude treating errors as "fatal"
unless such treatment is specifically allowed in the spec.  For
example, in 4.3.3 it might be appropriate to permit processors
to optionally report fatal errors when the encoding declaration
is sufficiently broken.

Why was this definition made so weak and fuzzy?  Was it just that
there wasn't much implementation experience on which to draw?  If
so, I think that there's plenty of experience now!

- Dave
Received on Wednesday, 2 December 1998 17:17:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:29 GMT