Re: "Living Standards"

Hi,

I don't (yet) have an arrested view on this topic, but I wanted to react to a few things that Marcos said in the hope of clarifying up some aspects of the discussion.

On Dec 28, 2011, at 02:39 , Marcos Caceres wrote:
> Let me again give the XML 1.0 example (which comes from the Recommendation/static world). XML 1.0 is "never finished" so long as there are "Editions" being worked on, forever. The only difference in a living standards model would be that the "Editions" are not present: the document is just updated when an issue is found and a list of changes is maintained. That's all… well, and email would go out too, I supposed - letting people know that something has changed.  

Note that some of the changes between editions of XML 1.0 have had the potential to break things, even if mildly. Now for 99% of XML users, the chances that those changes would produce a severe crash are pretty low, but there are situations in which you really don't want to take that tiny chance. To take grim examples, XML is used in things like military communication protocols and medical interchange formats. You don't want to be the editor who triggered a cascade of failure there because different parties used a subtly different source for the spec.

For that sort of thing (and things less radically life-threatening), it's quite important to have an identifiable anchor that people can agree to interoperate against, write into contracts, etc.

Having said that, it doesn't really matter if that anchor is "Edition 17" or "Commit deadbeef". The important thing is to put people in control of whether they want the bleeding edge or a sta(b)le version.

I tend to think that a workable model could be use a specification development model similar to git-flow: http://nvie.com/posts/a-successful-git-branching-model/.

> Let me give you a recent example. In the Widgets Interface spec I published on the 13 December 2011, it was pointed out to me on the 15th of December by a concerned implementer that there was a mistake in one of the examples [1]. I accidentally wrote:
> 
>  if (event.storageArea === widget.localStorage) {  
> 
> And I should have written:  
> 
>  if (event.storageArea === *widget.preferences*) {
> 
> So, although there is a mistake in the spec that caused an implementer some concern (I was asked, "did you change the name of the attribute?"), I have to wait up to 1 month (or more, in most cases) before I can fix it on /TR/ (because of the publication freeze over xmas and because it would be huge pain to call for another CR just to fix a wee typo or two, etc… or because the exit criteria has not been met)… which means potentially more people becoming unnecessarily confused. As a slightly OCD-standards-editing-nerd, that's very frustrating: I want to push my change to TR now, and not in a month….

AFAIK this is not documented in the Process, but there's precedent for trivial errors such as this one to be edited in-place in /TR/ without jumping through the publication hoops. It's certainly what I'd recommend in this instance. Maybe this is something that ought to be more clearly documented?

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Monday, 2 January 2012 17:21:34 UTC