Extensibility and Uniformity; defining "error" behavior (was ZIP-based packages and ....)

Let me try to switch to a different "Subject" heading and see if anyone follows.

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".

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).

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. 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.

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. 

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 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.

Examples of reuse include HTML not just in browsers, but HTML email, HTML as a format interchange between disparate word processors, or HTML as text markup in directory entries; HTTP not just between browsers and web servers, but as the substrate for distributed systems (Web protocol), printing (IPP) and coffee pot controllers; URIs not just for links in HTML documents, but as endpoints in distributed session identification, semantic web ontologies and XML namespaces.

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. 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.

Larry

Received on Tuesday, 30 December 2008 13:03:53 UTC