[whatwg] Removing versioning from HTML

[Marcin Hanclik]

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 at lists.whatwg.org [whatwg-bounces at lists.whatwg.org] On Behalf Of João Eiras [joaoe at 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.