W3C home > Mailing lists > Public > www-tag@w3.org > December 2008

Re: Extensibility and Uniformity; defining "error" behavior

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 30 Dec 2008 13:36:47 +0000 (UTC)
To: Larry Masinter <masinter@adobe.com>
Cc: "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <Pine.LNX.4.62.0812301313370.12643@hixie.dreamhostps.com>

On Tue, 30 Dec 2008, Larry Masinter wrote:
> 
> This part of the discussion started over the assertion: "specs need to 
> define all behavior that is relevant for interoperability, including 
> error handling."
> 
> My point in referencing the IETF standards process document (RFC 2026, 
> BCP 9) http://tools.ietf.org/html/bcp9#section-3 was to point out 
> section 3 which distinguishes between a "Technical Specification" and an 
> "Applicability Statement".  These "need to define" different things, and 
> "error handling" belongs in an "Applicability Statement", not a 
> "Technical Specification".

My argument is that the W3C and the IETF should be in the business of 
writing "Applicability Statements", as you describe them, and that 
"Technical Specifications", as you are describing them, are worthless.


> The discussion seems to revolve around the apparently conflicting goals 
> of extensibility (broad applicability) and uniformity (defining behavior 
> precisely enough so that different implementations work the same), while 
> retaining "interoperability" (different implementations work together).

To obtain extensibility / broad applicability on the long term, one needs 
what you describe as "Applicability Statements". "Technical 
Specifications", as you describe them, do not, and indeed cannot, provide 
for extensibility of the languages or protocols described as soon as there 
are any widespread implementations.

To obtain unifomity / interoperability, one needs what you describe as 
"Applicability Statements". "Technical Specifications", as you describe 
them, do not, and indeed cannot, provide for unifomity / interoperability 
amongst implementations of the languages or protocols described, whether 
across one application or many.


> The suite of specs defining "the web" contains technical specifications 
> for languages, protocols, and protocol agents, including the HTML and 
> CSS languages, the HTTP protocol, and the URI protocol element.

As you describe them, the CSS 2.1 specification is an "Applicability 
Statement". I agree that the HTML4, HTTP, and URI specifications are what 
you describe as "Technical Specifications", and I am arguing that this has 
caused widespread problems with interoperability and extensibility across 
all applications.


> In addition "the web" also is specified by applicability statements for 
> particular software components: a browser, a proxy, a web server.  The 
> TS and AS aspects are in the same documents but they're different.

In practice, I do not think the "AS aspects" actually exist for most of 
the Web technology stack. They should; their absence has caused the Web 
massive problems with lack interoperability across applications.


> Leaving technical specifications open to extensibility is desirable; it 
> allows not only new kinds of existing softare components (e.g., browsers 
> for TV or touch screen handhelds), but also new kinds of applications 
> which reuse those technical specifications. Many different applications 
> reuse HTML, HTTP and URIs, not just browsers, and that reuse of those 
> technical specifications is fundamental to the power of the web.

What I am saying applies to all applications, not just browsers.

What you describe as "Technical Specifications" do not provide enough 
detail to enable extensibility. We need "Applicability Statements", as you 
describe them, to obtain the stability and reliability across all 
applications to be able to extend the languages and protocols reliably and 
predictably.

Many different applications reuse HTML, HTTP and URIs, not just browsers, 
and those different applications need to be able to interoperate. We can 
only achieve the high level of interoperability that we need to seriously 
consider the Web a platform if the specifications are as detailed as what 
you describe as "Applicability Statements".


> On the other hand, it is also useful to define applicability statements 
> which prescribe the behavior of particular software agents (using the 
> technical specifications). A definition of a "web browser" might include 
> its handling of HTML, HTTP, URIs and other languages, protocols and 
> protocol elements.

It is unreasonable for different applications to handle languages and 
protocols in incompatible ways, which is what would result from having 
different "Applicability Statements", as you describe them, for each 
application or software agent category.


> It is reasonable to expect that an applicability statement for a 
> particular class of software component might also be expected to further 
> define behavior in "error" situations, especially when describing how to 
> interact with the deployed infrastructure at the time of writing.

It is IMHO completely unreasonable for different application types to 
handle errors in different ways.

For instance, the problems I've described are not at all limited to just 
the traditional browser. A link checker, a search engine, a Web browser, 
and a validator, if a user is to have a consistent experience with his 
software, all have to process the user's data, such as an IRI in an 
ISO-8859-4 document, in the same way.


> Examples of reuse include HTML not just in browsers, but HTML email, 

If mail clients handled HTML differently than Web browsers or authoring 
tools, then authors would be unable to reuse HTML content from one context 
into another. This is an example of the kind of interoperability nightmare 
that results from having what you describe as "Technical Specifications" 
instead of having what you describe as "Applicability Statements" that 
apply to all applications.


> We've managed to do this with a set of specifications which have not 
> split into separate documents the "technical specification" parts from 
> the "applicability statement" parts, but the distinction is useful and I 
> think should be promoted.

We haven't managed to do it _because_ of the split between "Technical 
Specifications" and "Applicability Statements", we have managed to do it 
_in spite of_ the use of "Technical Specifications" instead of 
"Applicability Statements". IMHO the distinction is useful only insofar as 
it provides us with a way to know what to avoid doing.


> In the case of HTML, the split of the current document into a technical 
> specification ("the HTML language") and an applicability statement 
> ("definition of a web browser") would leave room for future 
> extensibility while also insuring uniformity of operation for the next 
> generation web browsers.

HTML5 doesn't define just the behavior of Web browsers. It treats as 
first-class citizens all HTML user agents, whether those be mail clients, 
validators, authoring tools, data mining tools, or, indeed, Web browsers. 
This is what all specification should do.

HTML5 also leaves room for future extensibility; indeed, by precisely 
defining the processing model for all applications, it provides a far more 
effective ability to extend the language in the future than previous 
versions of HTML, which only defined what you describe as "Technical 
Specifications".


If you disagree with this it would be helpful if you could make a 
point-by-point rebuttal of my earlier e-mails:

   http://lists.w3.org/Archives/Public/www-tag/2008Nov/0125.html
   http://lists.w3.org/Archives/Public/www-tag/2008Dec/0095.html

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 30 December 2008 13:37:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:09 GMT