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

RE: ZIP-based packages and URI references into them ODF proposal

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 29 Dec 2008 22:57:25 +0000 (UTC)
To: Larry Masinter <masinter@adobe.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <Pine.LNX.4.62.0812292230210.12643@hixie.dreamhostps.com>

On Mon, 29 Dec 2008, Larry Masinter wrote:
> 
> 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.

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, and the arguments I gave then IMHO apply in the same way:

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


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


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

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.

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.

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.

Similarly, if we were to extend XML's xml:preserve attribute to have a 
third value, we couldn't do so without checking how all the different XML 
processors would handle the new value, because XML doesn't define how to 
handle unknown values. Indeed it also doesn't define in useful detail how 
UAs are to handle the two values it _does_ introduce, and the result has 
been that everyone has come up with different meanings for those attribute 
values, and some of the interpretations can conflict (e.g. SVG's 
requirements for processing xml:space differ from the requirements of some 
proprietary languages, and thus the two can't be combined).


Not having detailed specs hurts interoperability, makes future innovation 
more complicated, and increases implementation costs.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 29 December 2008 22:58:02 GMT

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