W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Reference to the HTML specification

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Mon, 5 Sep 2011 21:11:04 +0200
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Jarred Nicholls <jarred@extjs.com>, Philippe Le Hegaret <plh@w3.org>, Doug Schepers <schepers@w3.org>, Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>, Ian Hickson <ian@hixie.ch>
Message-ID: <F98CA0C247FE456DA36630D2C50F622D@gmail.com>
Hi Julian, 

On Monday, 5 September 2011 at 20:54, Julian Reschke wrote:

> On 2011-09-05 16:13, Marcos Caceres wrote:
> > ...
> > Most don't, in my experience. Specially those from other consortia. They love cling the dated specs and then pretend they are somehow more stable then the Editor's Draft. It's simply nonsense, but the W3C Process document seems to codify this.
> > > bleeding edge quite often. It's a game of "who can have the latest and greatest first and the best".
> >  Not always so. Other industries believe that having a stable reference point will cut down their interop issues (specially for environments where it's difficult to update software). I know, how ridiculous and illogical is that?!
> > ...
> 
> Well, dated and immutable specs *indeed* are more stable. If you need 
> "stability" as in "what it says today it will say tomorrow as well" then 
> dated snapshots are the right thing to use.

Ok, for instance. Lets say I have a dated spec, and in there it says:

<h1>Awesome Feature</h1>
A user agent MUST implement big accidental security hole.

Two days later, we see that Awesome feature had an issue. The spec and test suite gets updated. 

Three days later, implementer X comes along and picks up Awesome Feature (or demands from some company that Awesome Feature be implemented, because it's in the "stable" spec). 

Stability cannot be measured by how frozen the *text content* is; only by how stable its features are (i.e., through a test suite, and evidence of reference or real implementation). Any other claims of stability are bogus and deceitful.

It's like slapping a 1.0 on a piece of software. It says nothing about its stability: just that someone slapped "1.0" on it. There are only a few milestones that matter in the spec process: FPWD, LC, and PR - but links to those IRP-relevant snapshots could be hidden away where only the lawyers, or really interested parties, could find them. 
> I do see that it's a problem when people use outdated specs; but maybe 
> the problem is not the being "dated", but how they are published. As far 
> as I can tell, there's not nearly as much confusion on the IETF side of 
> things, where Internet Drafts actually come with an Expiration Date.
I don't have any experience with IETF specs, but I'm sure the situation is probably the same over there (though expiring specs might help a little, so long as the spec expires a week or so after publication and is clearly marked as such). 
Received on Monday, 5 September 2011 19:11:24 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT