Re: New issue: error recovery practices (Re: Proposed TAG Finding: Internet Media Type registration, consistency of use)

On Wed, 29 May 2002, Tim Bray wrote:
> OK, let's try <stares blankly at screen for 10 minutes>
>
> It is architecturally sound, when designing a protocol or a language, to
> provide normative specification for correct behavior in the face of
> incorrect data.  This is observed to increase robustness and
> interoperability, and improve the quality of the software that processes
> the data.

Some suggested wording to add to this point:

"In general, it's poor design to silently recover from what are clear
errors. This is because the Web is comprised of many interlocking pieces
created by many different developers.  Many (most) developers learn
technologies not by reading specifications, but by observing behavior.
When implementations silently allow for poorly-formed input, developers
interacting with those implementations will assume that the poorly-formed
input is correct.  As incorrect code from these miseducated developers is
integrated into the Web, the Web becomes a more difficult place to
interoperate."

"When possible, specification writers should offer no room for
implementations to silently recover, and instead, should mandate behavior
that communicates error conditions to developers in the clearest possible
manner.  A very effective means is to halt processing entirely (such as in
XML), but that may not always be practical or desireable. However, more
subtle means of communication are almost always available (for example,
error icons on the display frame, withholding new features, log messages,
or warning headers in protocols).  Such solutions should be encouraged in
specifications, and mandated when practical."

> Examples of such architecturally sound specifications are [insert ref to
> XML] and [a couple of other examples of good practice, hopefully at a
> different level than XML in the protocol stack, and hopefully other than
> "halt and catch fire"... I think Chris claims this for SVG?].

Al Gilman pointed out XSL in his earlier email to this list, though I
don't understand XSL well enough to speak to his example.  The UAAG
document on error recovery would be a good thing to reference as well.

SMIL and SVG are both of the "halt and catch fire" variety.  That may be
good or bad, depending on your point of view.  SMIL 2.0 has much stricter
behavior than SMIL 1.0, and is an example of "withholding new features"
If one wants to write relatively sloppy SMIL 1.0, one doesn't get the
whiz-bang new features of SMIL 2.0.

> Examples of bad practice in this area are [insert reference to something
> that leaves the picture fuzzy].

HTML, circa 2002, though I wouldn't characterize it as "bad practice" so
much as "if we knew then what we know now".

> I think maybe the architectural point is not what degree of tolerance or
> draconianism the designer decrees, but that they take the trouble to
> specify what to do when things go wrong.

The bulk of the observations on this list tend to support a stronger
stance than that.  Current practice/inertia is to be more lenient than
what seems prudent.

> This seems like basic common sense and not something that we should be
> having to point out ex cathedra... is it worth taking up? -Tim

Simon SL beat me to the punch here.  Given existing practice, it's not
"common" sense.

Rob

Received on Wednesday, 29 May 2002 21:34:07 UTC