> 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.
Traditionally, there is a distinction drawn between a "technical
specification" and an "applicability statement". (See
http://tools.ietf.org/html/bcp9#section-3) The goal of the technical
specification is to define a language, interface, protocol or protocol
element in a way that only those things *necessary* for interoperability
are defined.
An applicability statement (such as "how to implement a compatible
browser in 2009") may further go on to define additional behavior,
restrictions, and handling of otherwise undefined behavior.
In practice, the distinction between technical specifications and
applicability statements has been blurred in the IETF, and isn't
explicit at all in W3C, but but it is a useful distinction that I
think could help sort out objectives. *Some* specifications may
need to define "error" behavior, but not *all* specifications.
I'm hoping that the web architecture might include technical
specifications of the HTML language, HTTP protocol, and URI protocol
element (among others) as well as an applicability statement for what
is required to implement a compatible browser would give us both the
grounds for innovations, applications HTML outside the traditional
"browser", as well as a basis for better browser compatibility than
we have today.
Larry