


From: Ian Hickson <ian@hixie.ch>
Date: Mon, 29 Dec 2008 13:26:37 +0000 (UTC)
To: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <Pine.LNX.4.62.0812291309170.12643@hixie.dreamhostps.com>

On Mon, 29 Dec 2008, Julian Reschke wrote:
> Your assumption seems to be that there's a single "good" way to define 
> this error handling. I disagree with that.

There are many ways to define error handling; they each have different 
advantages and disadvantages. My point on this thread was not to support 
one over another. I am only saying that specs need to define all behavior 
that is relevant for interoperability, including error handling. Merely 
defining valid behavior and leaving all other behavior undefined is not 
enough -- it leads to lack of interoperability, such as the many 
differences between Web browsers, Web servers, and other tools today.

Note also that I'm not trying to single out error handling here. It is the 
processing requirements that need to be defined in detail. To use XML as 
an example -- XML doesn't actually define how to parse XML, and thus there 
is no concept of the processing of an end tag, which then makes it very 
hard to define things such as document.write(), SVGLoad events, <script> 
processing, etc, in languages that use XML. It also doesn't define the 
error handling for incorrect values on the xml:space attribute.

> For instance, for XML, sending non-ASCII characters when the declared 
> encoding is US-ASCII is a fatal error, and I definitively want to stay 
> it that way.

XML does a much better job than most specs at this, but it still leaves a 
lot undefined, e.g. the cases given above, or whether errors in XML 
resources in applications that are processing the results incrementally 
should cause earlier output to be replaced by an error message or whether 
the results can continue to be shown and can continue to be interactive 
[1], or how error messages should be represented in higher-level 
structures such as the Infoset or the DOM.

[1] http://lists.w3.org/Archives/Public/www-tag/2008Dec/thread.html#msg48

Received on Monday, 29 December 2008 13:27:13 GMT
