errors and failures (was Re: Minutes of 27 May 2002 TAG teleconf)

Perhaps I'm jumping the gun on this one, but there does appear to be a
substantial set of architectural issues surrounding error-handling on
the Web. I find the TAG's uneasiness in addressing this issue deeply
troubling.  Error-handling is often discussed as one of the best
features of the Web, permitting imperfect communications to take place
in a clearly-understood set of contexts.

HTTP's 404 Error - and others like it - were initially viewed with
disdain by closed-system hypertext people who were used to much more
tightly-controlled universes where they could prevent such errors. 
Nowadays I think we all recognize that humans are capable of dealing
with a 404 Not Found Error, and that the Back button or equivalent is an
adequate tool for coping with it. (404 response pages providing guidance
are better, but optional.)  DNS errors have similar error-handling.

On the HTML side, however, the lax approach to structure which initially
made it easy to get pages onto the Web is now strangling us as
developers try to do more with the Web.  Dynamic HTML and its brethren
were an early sign to one group of Web developers that more careful
coding was necessary.  Browser-war madness where vendors tried to keep
up with each other's idiosyncratic corner-case handling was another
consequence.  Perhaps the saddest consequence of all is the large number
of tools for working with HTML (as HTML, not just text) which still spit
out poorly-formed and not valid HTML with the understanding that it's
the browser's job to cope.

XML seemed to signal a change in this approach, taking much of HTTP's
"it's okay to show errors to users" instead of HTML's "do your best no
matter how potent the stench".  The XHTML specification seems to follow
the XML route, but implementations are still catching up.

Is error-handling an architectural issue for the Web?  I believe it
clearly is.  404 Not Found is a critical component of HTTP processing, a
key element of the Web's use of hypertext.  It doesn't always work, and
it's okay to admit it.  Web site developers have learned to cope with
this problem and haven't been screaming that browsers should just fix
it.

On the content side, it seems like it's (past) time to take a similar
approach.  Applications which purport to use XML are required by the XML
1.0 spec to fail when presented with malformed XML.  (Validity is
treated separately.)  Should that foundation also be optional?  If it
is, the consequences for the Web architecture are pretty far-reaching,
removing much promise for machine-processing of information.  If that
foundation is optional for XHTML, should it be optional for SOAP?  RDF?

I'd strongly recommend that the W3C take a much harder-line on error
reporting for content than it did up to HTML 4.0, and that it bring
error-handling for content into the same general framework as
error-handling for transfer.  I'm sure that some of the membership will
be deeply unhappy, but the Web as a whole will be better able to advance
into new areas.

On Mon, 2002-05-27 at 18:15, Ian B. Jacobs wrote:
> Accept issue raised by Rob Lanphier?
> 
> See [16]issue raised by Rob Lanphier asking "What is appropriate
> error resilience/recovery/"second guessing" in web software?".
> 
>   [16] http://lists.w3.org/Archives/Public/www-tag/2002May/0124
> 
> <Ian> TB: I think there is no new issue here? Seems too
> general. Not sure what the recommendation would be. There are
> issues in RL's email, but as framed, I'm not sure what you could
> make a finding about.
> 
> <Ian> IJ: What about asking QA to answer this in its guidelines?
> 
> <Ian> TB: I think there are issues here that are not just QA
> issues, but as written too much conflated.
> 
> <Ian> Action TB: Respond to RL on the list asking for more
> detail.
> 
> <Ian> Resolved: Do not accept this as a TAG issue (but do not
> decline).

 
-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com

Received on Tuesday, 28 May 2002 11:30:52 UTC