intertwingly

I’ve been having fun working on the URL Living Standard. The first change I landed was to convert the spec from Anolis to Bikeshed. Here’s the before and after after. And just for fun, here is the beginning on 2014 and beginning of 2013. The point being that arbitrary snapshots of living standards do exist.

Along the way, I’ve been named by my employer’s AC member to be a member of the W3C WebApps Working Group, and invited to become a member of the WHATWG organization on GitHub. I’ve been named as co-editor of the spec in both organizations, and at that point the fun abruptly stopped. Apparently, the larger political issues that I had successfully avoided in the past moved front and center.

Here’s what I said in September:

While I am optimistic that at some point in the future the W3C will feel comfortable referencing stable and consensus driven specifications produced by the WHATWG, it is likely that some changes will be required to one or both organizations for this to occur; meanwhile I encourage the W3C to continue on the path of standardizing a snapshot version of the WHATWG URL specification, and for HTML5 to reference the W3C version of the specification.

Now it is time for me to spell out how I see that happening.

I’ll start out by saying that I continue to want the WebApps WG to follow through on its charter obligation to continue to publish updates to the URL Working Draft. And once updates resume, I want to work on making doing so entirely unnecessary. While this may sound puzzling, there is a method to my madness. I want to establish an environment where an open discussion of this matter can be held without anybody feeling that there are options that are closed to them or that there is a gun to their head.

Next I’ll state an observable fact: there exists people who value the output of the W3C process. The fact that there are people who don’t doesn’t make the first set of people go away or become any less important. Note that I said the output of the W3C process. People who value that don’t necessarily (or even generally) want to observe or participate in the making of the sausage.

What they value instead is regular releases and making the bleeding edge publicly available. And for releases, what they care most about are the items that are covered during a W3C Transition (example). In particular, they are interested in evidence of wide review, evidence that issues have been addressed, evidence that there are implementations, and the IPR commitments that are captured along the way.

Some have (and do) argue that these needs can be met in other ways. Not everybody is convinced of this. I’m not convinced. In particular, the existence of a bugzilla database with numerous bugs closed as WORKS4ME without explanation doesn’t satisfy me.

To date, those needs have intentionally not been met by the WHATWG. And an uneasy arrangement has been created where specs have been republished at the W3C with additional editors listed, in many cases in name only. Those copies were then shepherded through the W3C process. Many are not happy with this process. I personally can live with it, but I’d rather not.

I said that this will require changes by one or both organizations. I will now say that I expect this to require cooperation and changes by both. I’ll start by describing the changes I feel are needed by the WHATWG, of which there are three.

1. Agree to the production of planned snapshots. And by that I mean byte-for-byte copies. As a part of this that would mean the identification of "items at risk" at early stages of the process, and the potential removal of these items later in the process. These snapshots will need to meet the needs of the W3C, primarily pubrules, and only linking to W3C approved references. Even though it should have to go without saying, apparently it needs to be said: those specs need to be snark free. Finally I'll go further and suggest that those snapshots be hosted by the W3C, much in the way that the W3C hosts WHATWG's bugzilla database and mailing list archives.

2. Participation in the production of Transition Requests. That would involve providing evidence of wide review and evidence that issues are addressed. It also could include, but doesn't necessary require, direct participation in the transition calls.

3. Understanding and internalizing the notion that the combination of an open license coupled with begin unwilling or unable to address a perceived need by others is a valid reason for a fork. Yes, I know that the W3C hasn't adopted an open license themselves, and I believe that is wrong too. But that doesn't change the fact that an open license plus an unmet need is sufficient justification for a fork.

I’ll close my discussion on the WHATWG changes I envision with a statement that participation in the W3C process (to the extent described by #1 and #2 above) is optional and will likely be done on a spec by spec basis. Editors of some WHATWG specs may not chose not to participate in this process, and that’s OK, I simply ask that those that don’t recognize the implications of this choice (specifically #3 above).

Responsibility for advancing specs for which the WHATWG editors voluntarily elect to participate in the process would fall to a sponsoring W3C Working Group. Starting to sponsor, ceasing to sponsor, and forking a spec would require explicit W3C Working Group decisions. As a general rule, Working Groups should only consider sponsoring focused, modular specifications.

Here’s what sponsoring would (and most importantly, would not) involve:

1. No editing. As suggested above, snapshots produced by the WHATWG would be archived, but these archives would be byte-for-byte beyond the changes involved in archiving itself (example: updating stylesheet links to point to captured snapshots of stylesheets). The one possible exception to this would be in the updating of normative references, but this would only be done with the concurrence of the WHATWG editors.

2. Participation would be limited to the production of Transition Requests. This would include providing evidence of wide review, evidence that issues are formally addressed, recording and reporting of Formal Objections, collecting patent disclosures, etc.

That’s it. Of course, the process will remain the same for documents that are copied and shepherded instead, but I see no reason that WebApps WG couldn't sponsor the WHATWG URL standard through this process, the HTML WG couldn't do the same for the DOM standard, the I18N WG couldn't do the same for the Encoding standard, etc.

While everybody may come into a sponsorship collaboration with the best intentions, we need to realize that things may not always go as planned. There may be disagreements. It has been known to happen. When such occurs:

1. Everyone involved should work very hard to resolve the dispute as the consequence of breakage is very bad all around.

2. If no agreement can be reached, the W3C Working Group will likely stop the sponsorship of the specific spec involved in the dispute.

3. If a Working Group stops sponsoring a spec, the Working Group could still fork that spec - but that would be a suboptimal solution for both W3C and WHATWG. It would also re-inflame the debates between organizations.

4. Nonetheless, since each organization has different criteria, we must recognize that this could happen; especially for large, broad, complex specs. Accordingly it makes sense for both organizations to continue the trend towards smaller and more modular specifications

I have no idea if others are willing to go along with this, but I hope that this concrete proposal helps anchor this discussion. I invite others that are inclined to do so to suggest revisions or to create proposals of their own. As an example, since the above describes an environment of collaboration and sharing of work, perhaps co-branding may be worth exploring?

This clearly will take time. As an editor of the URL specification, I’d like to propose that it be the first test of this proposal. In the meanwhile, I plan to spend my time coding.

For those that wish to dig further, a few links: