Re: WHATWG/W3C collaboration proposal

On 2014-11-21 09:59, Sam Ruby wrote:
>
>
> On 11/21/2014 11:59 AM, Michael Champion (MS OPEN TECH) wrote:
>>>> http://intertwingly.net/blog/2014/11/20/WHATWG-W3C-Collaboration
>>
>>> Thanks for asking.  I'm just one person in this CG, but my first
>>> reading agrees that it is not clear that any process change would
>>> be required.
>>
>> That's also my initial read.  I think this is consistent with the
>> letter and spirit of the revised process document:  what's important
>> when finalizing a Recommendation is the extent of consensus, RF
>> patent commitments, and interoperable implementation experience at
>> the end of the process, not the mechanisms of how the spec got
>> written and reviewed.
>>
>> I like the idea of using the URL spec as a test case, but I wonder if
>> we shouldn't use this opportunity to go further and try out some of
>> Robin Berjon's ideas (if I recall various TPAC conversations
>> correctly):
>>
>> - having a common GitHub repository for WHATWG and W3C versions of a
>> spec and shipping W3C Recommendations off a "stabilizing" branch
>
> From a technical perspective, there is no practical difference between a
> git branch and and git repository, other than ACLs.
>
>> - Hosting that repo and the discussion forums for a spec in a neutral
>> venue such as WebPlatform.org to encourage broader participation.

A neutral space for discussions may be a way to get both parties in the 
same forum for work on particular specs.  The issue is what would the 
decision policy be.  There seems to be a fairly fundamental disagreement 
on how decisions should be made.  Unless this presumes editors own the 
spec - if that's it I'm not sure I see why this isn't the equivalent of 
everyone doing it in whatwg and w3c deciding if it wants to bless 
snapshots (which I think is Sam's proposal).

For what Sam proposed, it looks to me that it gives an W3C influence 
only at Candidate REC and later  (and influense only if WHATWG cares 
about these snapshots). That is so late that many things would be widely 
implemented and difficult to change.  It seems just a way to provide 
feedback to the WHATWG and a decision made late on whether it's OK for 
W3C to create a (snapshot) spec that W3C patent policy applies to.  I 
can see why that may be of some use if the work can't move back into 
W3C, but it seems like giving up on that.  I'd need to look at this more 
carefully, but I'm not sure why we'd join that WG.  If the work is in 
the WHATWG then we could go do it in the WHATWG and make recommendations 
directly there.  So, the WG becomes the equivalent of signing the FSA in 
the WHATWG CG, something people can already choose to do I assume.

Another alternative (at least for some new specs):
1. W3C creates a second Permissive Document License that is roughly the 
W3C Software License (but without text about software that is confusing 
when applied only to specs).  So a license that permits the widest 
possible relicensing to other licenses.
2. Let W3C WGs choose that license for all their deliverables (specs and 
other docs) or just for specific ones.  Alternately, a WG could use the 
old Doc License and not allow forks.   Let CGs publish under that 
license if they wanted to.
3. Use Github to develop the specs in a WG with a license file 
indicating the new permissive doc license and a contribution file 
defining patent licensing commitments for patent claims essential for 
implementing ones own contributions in the spec they are contributed to 
(from one's employer - unless that's waived because the employer isn't 
relevant)
4. Decisions made by Chair based on consensus
5. Given the licensing model, if some don't agree with the decision they 
can fork in their own repository.

What that could do is allow the WHATWG or some other group work in W3C 
on a spec.  W3C gets the version they want.  If the WHATWG disagrees 
they fork that part.  And yes, that's a fork, but that's life.  But, for 
most of it, is done together in one place.  That is done with a license 
that makes it so if anyone is unhappy at any point, they can walk and 
work on it elsewhere.

This wouldn't have to be for everything.  it could just be for some new 
specs.  It would depend only on the AC/Director approving the WG Charter 
to do it.  For something specifically, done with the WHATWG, they could 
have their own branch in the main repository for things they disagree 
with W3C on.

Something like this could be experimented with on a small number of new 
specs.  And not just for specs done with the WHATWG.  it's a more 
general model.  (but is useful only for specs that W3C is comfortable 
with licensing under the proposed new permissive document license).



>
> If such were to exist, I would be glad to participate.  I mentioned ACLs
> above.  While the set of WHATWG and WebApps editors overlap (me!), they
> are not identical.  We'd also have to work out the licensing issues.
>
>> - Experimenting with modern forum tools such as Discourse to seek to
>> avoid fragmenting the discussion across  emails, IRC chats, GitHub
>> comments, Bugzilla, etc.
>
> If such were to exist, I would be glad to participate.
>
>> Another thought I'd like to discuss that may or may not be consistent
>> with your thinking, Sam: Could we find a consensus across
>> implementer/developer/user stakeholders  about a sensible division of
>> labor between WHATWG and W3C?  WHATWG folks have undeniable expertise
>> in documenting algorithms by which real-world markup  and URLs can be
>> parsed in an interoperable way. But these documents are not
>> necessarily useful guides to website developers crafting URLs or web
>> pages.  There is room for both a  "how to make a proper URL" spec and
>> a "how to parse a real-world URL" spec.   Maybe the IETF has already
>> done the former and there is no work for W3C to do in that space, but
>> if not it seems like a good job for the W3C WebApps or HTML WG to
>> take on.  Clearly the effort Anne started and you have joined on
>> documenting how to parse URLs needs more work. Many I've talked to
>> would be happy to see it published by WHATWG, if they produced stable
>> (non-snarky) snapshots with credible patent commitments and
>> documented interoperability.
>
> That's a mouthful.  Peeling off a few pieces:
>
> I have proposed what I consider to be a sensible division of labor.  
> It clearly is not the only possible division of labor, and I encourage 
> everybody to either suggest modifications to my proposal or alternatives.
>
> I agree that the URL Living Standard as it currently exists is not as 
> useful as it could be to website developers.  I'm actively working on 
> that.  You can see my progress here:
>
> http://intertwingly.net/projects/pegurl/url.html#parsing-rules
>
> I welcome feedback on that effort, though public-w3process is not the 
> right place for that.  I have a few links at the top of the document 
> for suggestions.
>
> As to whether RFC 3986 is a suitable base for this work is an open 
> question, and I believe the TAG and the IETF are intending to publish 
> something on this later this month.
>
>> The more fundamental question is whether the WHATWG folks are
>> interested in *either* doing some extra work to create real
>> reference-able standards under their own brand, or whether they would
>> work under a scheme such as Sam is proposing to collaborate on
>> stabilizing/testing/getting IPR commitments under the W3C umbrella.
>> One way or the other the larger communities of Web stakeholders need
>> useful and powerful but also stable and interoperable specs they can
>> use with some confidence that no one will come after them for
>> royalties.  A revitalized W3C-WHATWG collaboration could produce all
>> that, or the rest of the world will find some other way to make it
>> happen.
>
> First, I'll caution that "real" is emotionally charged and 
> "reference-able" open to debate.
>
> Beyond that, I'll repeat that my proposal is only one possible 
> proposal.  If there is some other way to make it happen, count me in.
>
> - Sam Ruby
>
>
>

Received on Friday, 21 November 2014 21:03:37 UTC