W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: ISSUE-4: Versioning, namespace URIs and MIME types

From: Sam Ruby <rubys@intertwingly.net>
Date: Wed, 18 Feb 2009 17:03:52 -0500
Message-ID: <499C85C8.6000303@intertwingly.net>
To: Dan Connolly <connolly@w3.org>
CC: Larry Masinter <masinter@adobe.com>, Ian Hickson <ian@hixie.ch>, HTML WG <public-html@w3.org>
Dan Connolly wrote:
> On Wed, 2009-02-18 at 11:51 -0800, Larry Masinter wrote:
> [...]
>> The need for multiple libraries comes from having incompatible
>> languages or language versions. Incompatible languages and 
>> language versions should be avoided--- however, not providing
>> a way of detecting which of several incompatible languages
>> or language versions was intended is a head-in-the-sand way
>> of pretending like they don't exist, and makes the problem
>> worse, not better.

I don't think characterizing other people's arguments as 
'head-in-the-sand' promotes progress towards resolution.

> I don't think so; the summary of this issue
>   http://www.w3.org/html/wg/tracker/issues/4
> shows that there are some eyes-open arguments
> that lead to the conclusion that we should not
> provide a way of detective which of several
> incompatible languages was intended:
> 
> * L. David Baron "Version information" -
> http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html

Agreed.

We discussed this at length in the development of Atom.  Our conclusion 
-- which I understand may very well be at variance with the position of 
the TAG -- was that the way to deal with incompatible languages was with 
minting new namespaces, if the underlying format has namespaces, or with 
the minting of new MIME types if not.

This was based on the observation that once a language is released out 
into the web, the amount of changes that can effectively be made is 
severely curtailed.  Evolution of languages, primarily by additions is 
possible.  Changes or deprecations rarely are.

I'm part of the ECMAScript committee.  Very similar constraints are in 
place there too.  Perl, Python, and Ruby can reinvent themselves; 
JavaScript never will have that luxury.

This is a hard discussion, one that doesn't lend itself to pat answers. 
  My personal thinking tends to align with Mark Nottingham's

   http://www.mnot.net/blog/2009/02/18/x-

The comment thread on that post is also enlightening, in particular 
Julian Reschke's; which has a pretty obvious parallel to the situation 
the IE team faces today.

- Sam Ruby
Received on Wednesday, 18 February 2009 22:04:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:32 GMT