RE: Extensibility and Uniformity; defining "error" behavior

Reply to both your earlier email and this one (at least some
of the points):

> I think the distinction between "technical specification" and "application 
> statement" is the same as the distinction you drew between "definition of 
> protocol, format, language" and "implementation functional specification" 
> last month,

Not exactly; I found a reference which explained the distinction
and gave some historical context.


> and the arguments I gave then IMHO apply in the same way:
>   http://lists.w3.org/Archives/Public/www-tag/2008Nov/0125.html

I think you are talking about "uniformity" when you use the word
"interoperability".

I also think you're using the word "extensibility" in a very narrow
sense; HTML extensibility is important not just for the next version
of web browsers, but also for new applications which aren't browsers
at all. There is no reason to bake into webapps all of the funny
processing rules necessary to deal with current broken HTML on the
Internet, and many reasons not to. So the error handling rules for
HTML browsers *should* be allowed to be different from the error
handling rules for HTML in webapps, and making them the same does
a disservice to both communities.


>> 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 disagree. This isn't limited to error behavior, either. All serious 
> specifications that are intended to help achieve any useful level of 
> interoperability must describe implementation requirements in enough 
> detail that different classes of user agents can all interoperate without 
> having to reverse engineer each other.


Again, you are using "interoperate" where I think you mean
"operate similarly".

Further, it seems like the "without having to reverse engineer" goal
is taken from the narrow perspective of "implementer of next generation
browser."   if you want to give advice about how implementers of
software components should write their software such that it will
interoperate not only with new software components but also the
existing deployed infrastructure, it would be equally useful to
tell creators of dynamic HTML generation software how to interoperate
with the existing deployed base of browsers, including old versions
of IE, again, "without having to reverse engineer".


> Application statements don't limit innovation. In fact, having detailed 
> specifications that define the precise rules for parsing and that give 
> precise rules for the processing models and so forth dramatically increase 
> the ease with which the respective protocols can be extended, because 
> there is no guesswork about exactly how various implementations are going 
> to handle the new syntax.

I agree that "Application statements don't limit innovation", but for
a different reason. An application statement limits the scope in which
the precise rules of operation are bound, such that a new application
might follow different rules while using the same underlying technical
specification.

> For instance, adding a new property or new syntax to CSS is easy, because 
> CSS defines forward-compatible parsing rules, so there is no ambiguity 
> about how a down-level browser is going to process new features. However, 
> adding a new element to HTML is incredibly difficult, because every 
> browser differs in how it handles unknown syntax, because the specs never 
> covered this case.

It's very difficult to get forward extensibility right, because it
requires some guesswork as to what extensions are desirable. While
planning for extensibility is useful, it's not sufficient.

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

I think this is hyperbole, and that your later remarks indicate
that what you mean is that they are insufficient, by themselves,
to accomplish the goal of uniformity of behavior for the web.

A well, written technical specification which is commonly observed
is quite useful -- even if it doesn't specify error behavior -- to
provide for interoperability between two agents which implement
the technical specification. 

In most situations, this has been sufficient to provide for
interoperability.

I believe and accept your concerns that it isn't sufficient for
some purposes, and in particular, isn't sufficient for implementers
of the next generation of web browsers.

It is also not sufficient for search engines, those who want to
archive web content for the future and other applications, but I
think those applications have additional requirements.


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

The HTTP specification goes to some trouble to separate out requirements
for user agents vs. clients, for proxies, servers, caches, gateways etc.

Received on Tuesday, 30 December 2008 14:23:44 UTC