Re: HTML.next and Rechartering

On Fri, 09 Sep 2011 01:48:45 +0200, Carr, Wayne <wayne.carr@intel.com>  
wrote:

>>> 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.

Indeed. It might be that this group suggests to W3C at large that Last  
Call has sufficient problems that W3C should investigate de-coupling it  
 from a crucial point of Patent Policy. Although that will take time, and  
the discussion is larger than the HTML WG.

> 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.

Another way is to track sections of specs according to some stability  
model based on implementation status. It will be hard to do that in a way  
which doesn't enforce some anti-competitive rule like "whatever the big X  
choose to do is the standard" nor fall into the trap of allowing a couple  
of unrealistic implementations to drive the industry into a requirement  
that makes no sense. And again, I think it's something for W3C process in  
general, rather than the HTML WG.

> 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.

There are other issues with "living standards" like testing, writing a  
Statement of Work against them, and the assumption that most people need  
to care about things that might change...

> None of that is a usual topic in a WG.

Right. Although since process directly affects WGs, all of them are  
reasonable places to generate feedback for the maintainers of the process  
(in W3C that is formally the AB, and you can consider your feedback heard).

cheers

>> -----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
>> confidence.
>>
>> 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
>> attracts.
>>
>>
>> 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.  
>> :-)
>>
>> Cheers,
>> Silvia.
>>
>>
>> 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
>>>
>>>
>


-- 
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Sunday, 11 September 2011 19:04:31 UTC