W3C home > Mailing lists > Public > public-html@w3.org > September 2011

RE: HTML.next and Rechartering

From: Carr, Wayne <wayne.carr@intel.com>
Date: Thu, 8 Sep 2011 23:48:45 +0000
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Sam Ruby <rubys@intertwingly.net>
CC: "public-html@w3.org" <public-html@w3.org>
Message-ID: <52F8A45B68FD784E8E4FEE4DA9C6E52A16E98EF5@ORSMSX101.amr.corp.intel.com>
>>I personally don't think that the "Last Call" stage means much,

It means a lot to lawyers.  Last Call is when patent commitments come into play for changes after the first public Working Draft (first formal W3C public Working Draft, not an editor's draft).  That's why substantive changes can't happen after Last Call without returning to another Last Call.

When companies are asked to make patent commitments that puts constraints on how vague charters can be and also on needing a fairly small number of fixed times when lawyers need to worry about drafts.  Breaking up specs into smaller specs that each develop at their own rate is one possible way of dealing with that, instead of very large specs.

It would be interesting to see how legal departments could deal with "living specs" that continuously change when patent commitments are involved that go beyond your own contributions.  The idea now is that you take a look when there are going to be no more substantive changes.

None of that is a usual topic in a WG.

>-----Original Message-----
>From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
>Behalf Of Silvia Pfeiffer
>Sent: Thursday, August 11, 2011 3:22 PM
>To: Sam Ruby
>Cc: public-html@w3.org
>Subject: Re: HTML.next and Rechartering
>Hi Sam,
>That poll asked a very difficult question that I didn't feel I could answer with any
>I believe there are indeed features in HTML that should be published as "stable"
>and that could easily be published as a HTML5 spec, giving application developers
>out there confidence that these features won't change any more and that
>browser support them, because they are implemented in all major browsers in a
>compatible manner.
>However, there are also many features that are only in specification state or still
>under discussion or implemented only in one browser.
>I personally don't think that the "Last Call" stage means much, actually. I believe
>that the "Recommendation" stage means a lot more.
>I also believe that we have features that are ready for the "Recommendation"
>stage, but others aren't ready for "Last Call" yet.
>I would much prefer if we could much the development of HTML to a model
>where the stages are attached to features rather than the full document. We
>could, for example, right now split out all those features that are stable (i.e.
>satisfy the "Recommendation" criteria) and call that document "HTML5 as of
>today's date". Then we could make a list of features that are almost there and
>put them at "CR" level saying that we are confident as a committee that this is
>stable, but it just needs some more implementations. These could then also be
>features that browser vendors could prioritize for implementation, because they
>will have a large impact towards cross-browser compatibility. And so on - you get
>the picture.
>This is somewhat the way in which the W3C process is describing things (as in:
>only features that are stable are allowed to enter "PR"
>stage), but for whatever reason we in the W3C define maturity on a per-feature
>level, but only publish on a document-level.
>Maybe it has something to do with the version control systems that we typically
>used: CVS and SVN are particularly bad at dealing with branches and merges. But
>we have now moved to Mercurial, so a more fluid approach to the creation of
>new features and their inclusion into the full HTML spec is possible.
>To me it makes sense to have a "stable" (or "PR") branch of the spec, then a "CR"
>branch with includes the stable spec plus any features that are almost there, and
>finally a "WD" branch with the features that are still under development and
>highly likely to change. Features will be "merged up" into the next stage branch
>based on group decisions.
>What we define as a "feature" can be rather flexible. It could be an element with
>all its attributes and IDL and rendering requirements. It could also be just a single
>attribute. It all depends on how much discussion/support/objections a feature
>So, while I sympathize with the spirit of the W3C process, I think our execution of
>it is rather unsatisfactory and I feel unable to make an informed decision on
>whether the HTML specification in its completeness should actually move
>forward in the maturity or not. I want it to move forward, but at the same time I
>want to really hold back on large parts of it. This is why I'm not able to vote on
>such a decision.
>Sorry about the lengthy and somewhat off-topic reply, but you did ask. :-)
>On Thu, Aug 11, 2011 at 10:55 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>> On 08/10/2011 10:12 PM, Tantek Çelik wrote:
>>> I tend to agree with Sylvia, and furthermore, am not convinced that
>>> the current feature set of HTML5 is a good "checkpoint" by any
>>> measure (implementation, feature stability, etc.) both from a
>>> perspective of features in the draft and features outside the draft.
>>> I think letting HTML5 evolve a bit longer and seeing if there is a
>>> convergence point among implementations and what features are or are
>>> not supported would be a better approach.
>> Do either of you have any specific features in mind?  Can you please
>> verify that there are existing bug reports and/or that these features
>> are added to the wiki page:
>> http://www.w3.org/wiki/HTML/next

>>> I don't think a spec-wide "Last Call" draft or period helps this
>>> purpose and thus perhaps that aspect/phase of the process should
>>> itself be called into question.
>> We proceeded to Last Call based on the results of the following poll:
>> http://www.w3.org/2002/09/wbs/40318/html5-last-call-poll/results

>> I do encourage both of you to participate any such polls that we might
>> have in the future.
>>> Thanks,
>>> Tantek
>> - Sam Ruby
>>> -----Original Message----- From: Silvia
>>> Pfeiffer<silviapfeiffer1@gmail.com> Sender:
>>> public-html-request@w3.org Date: Thu, 11 Aug 2011 11:34:26 To: Maciej
>>> Stachowiak<mjs@apple.com> Cc: HTML WG LIST<public-html@w3.org>
>>> Subject: Re: HTML.next and Rechartering
>>> On Thu, Aug 11, 2011 at 8:57 AM, Maciej Stachowiak<mjs@apple.com>
>>> wrote:
>>>> Hello Working Group,
>>>> Now that the Last Call period is over, it's a good time to start
>>>> thinking about the next steps in the evolution beyond HTML5.
>>>> There are a few ways we can start thinking and talking more about
>>>> HTML.next:
>>>> 1) Let's start up some discussion and collection of post-HTML5
>>>> feature ideas.
>>>> 2) Though we cannot yet publish post-HTML5 deliverables as Working
>>>> Drafts, nothing stops us from creating Editor's Drafts. So current
>>>> editors and anyone else who is interested are encouraged to create
>>>> post-HTML5 proposed Editor's Drafts for consideration, in parallel
>>>> with the versions working their way through the LC process.
>>>> 3) To be able to publish post-HTML5 delieverables, we will have to
>>>> change the charter of the Working Group. There are two possible
>>>> tracks we can take: A) Come up with a detailed definition of the
>>>> requirements, scope, and expectations for our next-generation
>>>> deliverables, and cast that as a new charter. B) Update the current
>>>> charter and give a fairly loosely defined scope for post-HTML5
>>>> deliverables.
>>>> Option A is much more clear about the next phase of our work, which
>>>> is helpful in some ways, but it may require longer discussion to be
>>>> clear about the scope. Option B likely requires less careful wording
>>>> and negotiation. There is some interest in completing rechartering
>>>> by the time of TPAC 2011. To achieve that, we'd have to have a draft
>>>> charter ready in 3-5 weeks. We have W3C staff members who can help
>>>> with the drafting.
>>> Realistically, in 3-5 weeks, I don't think you can achieve 3.A) .
>>> Also I wonder why we'd want to put a restriction on the features that
>>> we want to add to HTML5. I think it's more productive to keep the
>>> features open and just continue working on the spec. Which is in fact
>>> already happening at WHATWG and it's good to stay in sync.
>>> Silvia.
>> http://www.w3.org/wiki/HTML/next


Received on Thursday, 8 September 2011 23:49:27 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:17 UTC