Re: "Living Standards"

Hallo,  

On Monday, 2 January 2012 at 17:18, Robin Berjon wrote:

> 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.
Except in the most most extreme of cases, I don't see how that can be avoided.  XML can be generated by hand, or by a  trillion different editors of a billion different versions, etc. It would be like saying "Your users can only produce XML with Version X of software Y, and it must only be processed with Version W of Software X." That does not scale (not even for the military or healthcare applications, which I assume needs robust systems with lots of redundancy and fault tolerance - so not to kill people unnecessarily …. which kinda goes against the point you are trying to make).  
> 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.

Again, that is only for certain types of applications (where the world is very contained and small). Applications and formats for a mass communication medium don't work by those rules (hence HTML5 parser). That's not to say that those rules can't be used by particular vendors, but applied to the Web it will (and has always) failed: imagine telling everyone they could only make HTML documents using DreamWeaver 3.1 and that those Document could only ever be rendered in IE6, but Windows SP1! (because someone might die if you don't!). Is anyone really gonna take a chance on that? or is there fundamentally something wrong with that kind of thinking? (I think there is, and should be discouraged!… specially if my life, or anyone else's, is going to depend on it).

> 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.
Sure, people should be afforded privacy to do such unspeakable (or murderous) things behind closed doors. The problem I raise is when such things try to get forced on the open Web, as once happened with Widgets.  
>  
> 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/.

Sure… those tags could just be "WD", "LC", "CR", etc. And changes could just be merged into the mainline once the editor is ready.  
  
> > 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?
My point is that there should be no hoop-jumping at all. It should just be deemed that a spec is in a given phase (e.g., "LC"), and the document is edited in place: that would make everybody happy. It would also do away with having to have multiple Last Calls in a row (which are bad, because WGs sometimes discard the Disposition of Comments for any preceding last calls and only record comments from the last Last Call). So, instead of issuing Last Call after Last Call after Last Call, the WG and Editor need to actively pursue feedback from vendors and other groups. Same applies to other phases. It would also address Hixie's HTML5 work around of the Big Red Warning (tm) (and put and end to Editor's Drafts - which would become the development branches in the GIT model).  

Kind regards,
Marcos  

--  
Marcos Caceres
http://datadriven.com.au

Received on Tuesday, 3 January 2012 02:17:40 UTC