- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Thu, 18 Apr 2013 21:28:33 -0400
- To: Marcos Caceres <w3c@marcosc.com>
- CC: Larry Masinter <masinter@adobe.com>, Anne van Kesteren <annevk@annevk.nl>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, Ian Jacobs <ij@w3.org>, Philippe Le Hégaret <plh@w3.org>, "www-tag@w3.org" <www-tag@w3.org>
On 4/18/2013 3:34 PM, Marcos Caceres wrote: > What does stable mean to you? I think you are thinking of a "static" draft, not a stable one. Because a static dated draft cannot possibly be more stable that a draft that has been updated to fix an issue or clarify something. I think that's actually too simple an analysis. It's often important for people to agree, over time, which version of a specification they agreed to observe. Let's say that my organization and yours agree to communicate according to some specification S. We set down that agreement in writing, and we point to an immutable, dated copy of S. Later it's determined that there is a bug in S, or perhaps others start to deploy improvements to the function defined in S. Clearly, it's of value to write new versions of the specification, say S', that fix the bug or document the improvement. Still, there can be advantages to having our original agreement reference the immutable version S. First of all, it's clear how we've agreed to communicate. Secondly, we can then make a conscious decision as to when we agree to interoperate using the fixed or improved version S'. When the community involved is the Internet, then of course deployment of new function is incremental. There is value in having specs that evolve rapidly and incrementally to reflect new function or best practices. Still, there are circumstances in which it's better to agree to interoperate based on stable, immutable versions of a specification, and to make changes explicitly. Noah
Received on Friday, 19 April 2013 01:29:01 UTC