- From: Larry Masinter <masinter@adobe.com>
- Date: Mon, 29 Dec 2008 06:48:16 -0800
- To: Ian Hickson <ian@hixie.ch>, Julian Reschke <julian.reschke@gmx.de>
- CC: "www-tag@w3.org" <www-tag@w3.org>
> 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
Received on Monday, 29 December 2008 14:49:08 UTC