Re: WHATWG/W3C collaboration proposal

In general this proposal seems good, and I'm very heartened by the responses here from various parties. However, it reminds me of something Robin and I tried with URL a couple months back that ended up floundering on irreconcilable differences, so I wanted to get those potential issues out in the open before we go too far down this path. I remain hopeful though!

The WHATWG's primary concern in any scenario like this is that the snapshots produced do *not* look like or act like reference-able specifications meant to be implemented or consulted by authors. This is a general principle, and any good-faith efforts to collaborate need to work within that framework. For example, here are two issues which we were not able to resolve last time around:

1. The snapshot must have no/minimal stylesheet. http://www.whatwg.org/specs/url/2014-07-30/ is an example.
2. The snapshot must have a title, or subtitle, that clearly reflects the purposes of the snapshot, and that it should not be used for implementations. We want to avoid "snarky", but something like "For IPR purposes" or "Not for implementations" would be important. (For those interested in commit-level snapshots for reference purposes, we can get the WHATWG producing and hosting such snapshots very quickly---within a week, I would anticipate. See http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0066.html for previous discussion of this.)

It's also important not to make references to the source WHATWG specification as "editor's drafts." The WHATWG is not a source for editor's drafts.

If the plan is, as Sam says and Jeff supports, that the copies would be virtually byte-for-byte, this should be no problem. The WHATWG can produce such snapshots easily, more or less as was done for URL already, but with a more agreeable title. We can even address Jeff's concerns by baking the W3C copyright statements and boilerplate into the header, much like was done with the FSA boilerplate for https://whatwg.org/specs/url/2014-07-30/. (That way, the snapshots don't have to be modified upon copying.)

Finally, Sam already emphasized this in his post, but I want to re-emphasize it: an arrangement like this works best if all involved try to avoid forks. This means changes are made in the source document, then flow upstream to the snapshot. As such, it would be appreciated if the collaborative feedback and community Sam is hoping to build was centered on the whatwg@whatwg.org list and whatwg/url GitHub repo, instead of e.g. confined to public-webapps or to whatever GitHub repo the snapshot ends up in.

So, what do you guys think? Is this feasible?

Received on Tuesday, 25 November 2014 16:54:42 UTC