- From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Date: Fri, 14 Aug 2009 21:48:29 +0200
Hi, Versioning is a larger topic recently: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0655.html http://lists.w3.org/Archives/Public/www-tag/2009Aug/0027.html http://lists.w3.org/Archives/Public/www-tag/2009Aug/0029.html I wonder whether there could be a consistent pattern through all the specs from WHATWG and W3C to handle versions. The issues and use cases are very similar if not the same everywhere. Thanks. Kind regards, Marcin ________________________________________ From: whatwg-bounces@lists.whatwg.org [whatwg-bounces@lists.whatwg.org] On Behalf Of Jo?o Eiras [joaoe@opera.com] Sent: Friday, August 14, 2009 9:35 PM To: WHATWG Subject: Re: [whatwg] Removing versioning from HTML On Fri, 14 Aug 2009 12:01:31 +0100, Ian Hickson <ian at hixie.ch> wrote: > On Sun, 9 Aug 2009, Aaron Boodman wrote: >> >> I frequently see the comment on this list and in other forums that >> something is "too late" for HTML5, and therefore discussion should be >> deferred. >> >> I would like to propose that we get rid of the concepts of "versions" >> altogether from HTML. In reality, nobody supports all of HTML5. Each >> vendor supports a slightly different subset of the spec, along with some >> features that are outside the spec. >> >> This seems OK to me. Instead of insisting that a particular version of >> HTML is a monolithic unit that must be implemented in its entirety, we >> could have each feature (or logical group of features) spun off into its >> own small spec. We're already doing this a bit with things like Web >> Workers, but I don't see why we don't just do it for everything. >> >> Just as they do now, vendors would decide at the end of the day which >> features they would implement and which they would not. But we should >> never have to say that "the spec is too big". If somebody is interested >> in exploring an idea, they should be able to just start doing that. > > I agree in principle. > I wholeheartedly agree with all the reasoning, but there are issues. From an implementor's point of view it is much harder to implement and keep up with a mutating specification. During implementation a stable spec is preferred. So versioning will allow an implementor to decide to implement the latest stable version of some spec, while work proceeds on a newer one. And when I refer mutating specification I'm not referring to the whole html5 spec, but each separate component, like web storage, web workers, video, etc... Currently, because specs are being edited and might take a while to get to CR, we have different implementors implement different parts of the specifications, and then meanwhile the specification mutates and implementors have to waste time updating their implementation which could have been right from the start. I understand that implementation feedback is necessary, but this is not very optimal. After a spec gets to CR it can't just mutate out of thin air, hence forking it into a new version is the way to go. Example: Gecko, Webkit and IE have localStorage, but the spec changed a few days ago to allow structured storage. ________________________________________ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Received on Friday, 14 August 2009 12:48:29 UTC