Re: WHATWG/W3C collaboration proposal

On 11/21/2014 11:59 AM, Michael Champion (MS OPEN TECH) wrote:
>> 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 to encourage broader participation.

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:

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 

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 18:00:09 UTC