Indicate relationship with the WHATWG

[frivoal]

Given the overlap in scope, and the fact that various specs have shared history, The WHATWG should be at least mentioned in the Liaison / External Group section, including an explanation why some specs that were started in one group were continued / forked in the other, what could cause this to happen again, and how we plan to coordinate.

[plehegar]

Proposed text: [[ A number of the specifications in the charter for the Web Platform Working Group are derived from specifications originally written at the WHATWG and still being maintained there. For these specifications, the Web Platform Working Group should make an effort to work with the WHATWG editors to avoid differences between the WHATWG and Web Platform WG specifications that would harm interoperability on the Web. ]]

[dbaron]

One proposal would be to add text such as:

A number of the specifications in the charter for the Web Platform Working Group are derived from specifications originally written at the WHATWG and still being maintained there. For these specifications, the Web Platform Working Group should make an effort to work with the WHATWG editors to avoid differences between the WHATWG and Web Platform WG specifications that would harm interoperability on the Web.

/cc @annevk @domenic @foolip @hsivonen @tantek

[jeffjaffe]

David, LGTM.

[frivoal]

Thanks, this is a useful addition.

However, even though I'm fine with what's written, I'm was expecting more information.

For instance, the w3c process isn't really designed for tracking documents that are being maintanined somewhere else at the same time, so clarification about how it applies would be appreciated. If someone objects to a change the whatwg makes to the spec on the whatwg's mailing list, and the web platform wg copies over that change, does that comment count as an objection? Do comments on the whatwg's mailing list count as wide review for the sake of a CR transition? Is the answer different depending on whether the documents are identical or not?

What kind of differences between the WHATWG's version and the W3C's version are expected? If the goal of this duplication IPR protection only, we should not merely "make an effort to work with the WHATWG editors to avoid differences", but actually keep the documents identical, at least as far as normative text is concerned. If there's more than this, then spelling out that goal explicitly would be helpful to know what kind of differences are expected or acceptable.

Maybe it is naïve to expect such information in a charter, but without it, it is not clear to me what the WG is being tasked to do.

[jeffjaffe]

Florian, several of your questions are hard to put into a Charter because they depend on the particular WHATWG editor and particular document. In some cases, we have succeeded working with Anne in keeping documents identical. For HTML, we tried that for a while, but with a spec that large in the end we were forced to differ in some places. As a remediation, we in W3C maintained a document of differences between the specs.

For those reasons, I would rather keep the Charter general and encourage all participants on all sides to work together to find means to maximize collaboration and minimize differences. Perhaps we should add such a statement to both the W3C Charter and the WHATWG document.

My goal of having the work in W3C is not exclusively for IPR. W3C prides itself for its consensus process and wide review (http://www.w3.org/blog/2014/10/decision-by-consensus-or-by-informed-editor-which-is-better/). Certainly WHATWG also strives for consensus, but we have different definitions of what that means.

[domenic]

I think the W3C has a choice to make. Does it want to be an organization whose main value proposition is to take work that others have done, and re-brand it and pass it through its own value system and IPR pipeline? Or does it want to be a place to encourage original work and collaboration?

Traditionally, much of the work on the core platform has been of the former sort. And indeed, looking at the proposed charter, a large swathe of the in-scope work items are of that fashion. If that's the direction that the Web Platform working group wants to take, I'd suggest making it explicit, and probably expanding the scope so that you can also start copying specs from Ecma, ISO, and the IETF. The consensus definitions and IPR policies at those organizations are different (especially the IETF), and so I'd suggest expanding the charter to include HTTP, the network stack, the JavaScript language, Internationalization, module systems, and more.

On the other hand, if the Web Platform working group wants to be a place for original work to take place, then it would be best for it to make a clear break with the copy-and-pasting past embodied in the HTML and (to a lesser extent) webapps working groups. In that case, excising the "intent to copy and paste" from the charter would be a welcome sign of a reinvigorated W3C that wants to position itself as a place to do original work. Groups like WebAppsSec and the CSSWG have already shown this model can work within the W3C, without the crutch of filling out their charters with work done by other standards organizations. It is my hope that the proposed Web Platform working group can be as productive as they are.

[rubys]

Dominic wrote:

I think the W3C has a choice to make. Does it want to be an organization whose main value proposition is to take work that others have done, and re-brand it and pass it through its own value system and IPR pipeline? Or does it want to be a place to encourage original work and collaboration?

I don't think that captures the issue. If you will permit me, let me back up provide some context, and then describe what I believe the real issue to be.

---

First a post from Michael Champion:

I strongly encourage W3C to charter WGs to standardize what works rather than to take a "if we standardize it they will implement" approach.

Compare it to a similarly timed post from MS2GER:

Who do you propose will construct such a "what is implemented" specification, and what useful work would you have them drop for it?

---

Oversimplifying and overgeneralizing, the W3C is, on average, interested in documenting the web as it exists. By contrast, the WHATWG is, on average, interested in documenting the web as they would like it to be.

There is plenty wrong with that generalization. After all, given how screwed up the web is, you can't document how it exists without being very creative. And the WHATWG won't accept anything that breaks the web so there are pretty severe limits to the amount of creativity liberties that one can take.

But that aside, I'm convinced that this difference in approach underlies most of the differences between the two organizations. And it is fair to observe that this difference shows up considerably more in stable specifications (like HTML and URL) and considerably less so in new specs (like Fetch and Streams).

---

For my part, I think the W3C needs to start with trying to answer MS2GER's question before it tries to answer yours (Dominic's).

I came to this conclusion the hard way. I tried to work on a a "what is implemented" version of the URL specification (as a user and a producer of content but not a browser implementer, I understandably am more interested in interop than futures), and did so with the explicit encouragement of individuals that worked for multiple browser vendors. Only to find out that implementers were not interested in focusing on that problem.

Meanwhile, work continues on the URL specification at the WHATWG, mostly defining and refining new APIs.

[annevk]

@jeffjaffe you haven't succeeded keeping any documents identical. Whoever told you that is wrong. I've also consistently pointed out I'm not happy with forking happening.

[jeffjaffe]

@annevk I guess I misunderstood or things have changed. Last I had checked, for example, I thought we had kept Encoding identical.

Should we get some folks together at Sapporo to discuss how to improve synchronization?

[annevk]

• https://encoding.spec.whatwg.org/ 6 September 2015
• http://www.w3.org/TR/encoding/ 16 September 2014

I would rather not talk about this at TPAC. It's not worth it.

[r12a]

I don't think that's an entirely fair comparison. It was identical when the snapshot was published, but changes have been made to the WhatWG version of the spec since, which the i18n WG treats as the editor's version (we don't have an alternative editor's version). We have been tracking those changes, which are typically arising from implementation experience, and the i18n WG is just awaiting an opportune moment to publish an update to the CR document so that we can resynch again. (As a number of open comments were addressed and closed quite recently, we were actually starting to think that a resynch should probably come fairly soon.)

(We could update the CR version more frequently, but the differences being largely implementation related, and seeing that the implementers are working from the WhatWG version, we have not felt a strong necessity so far. We are certainly open to persuasion on that.)

[annevk]

The fact is that I continue to get occasional feedback based on the out-of-date fork, meaning people's time is being wasted. If indeed the only reason for a fork is IPR, we should just label it as such to avoid any and all confusion.

[chaals]

The current approach is that we don't republish versions of work that is done at WHATWG - we either do the work of maintaining a spec, which as @annevk points out in his last message includes considering issues raised because there is a whatwg version - or not.

HTML is an example of a specification where we do publish a specification. We have removed, for example the URL spec from our new charter proposal draft as an example of a spec we are not working on.

If the text in that proposal about WHATWG isn't sufficient, please raise a new issue / PR

[annevk]

You are failing pretty badly at "The Web Platform Working Group should make an effort to avoid differences between WHATWG and Web Platform WG specifications that harm interoperability on the Web." so I'm not sure it's really working as stated.

[frivoal]

Whether that "effort to avoid differences" is successful or not should be view in the light of what the goal of maintaining the specification separately is. Differences that are a consequence of that goal are likely justified, while those that are not are issues.

My issue from the start has been and still is that I don't know what that goal is. I am not being facetious here, nor do I believe that there's no goal. However, I strongly suspect that one of the reasons we have not written it down is that different people have different rationales for this, and these various goals are mutually incompatible.

I am sure that the differences that were introduced are justified based on what the people who made them understand the goal to be. However, the continued inability to write that goal down make be believe that it is not a consensus based goal.

This is also why I have refrained from commenting on Calls for Consensus about resolving issues or publications. Not knowing what the mandate of the WG is, I have no basis to judge whether it's actions are appropriate or not. Theoretically, I suppose I could object to everything until the purpose is clarified, but I doubt this would be seen as a constructive approach, and ain't nobody got time for that.

The problem is that if a large part of the group's membership has a similar attitude, we'll have consensus by exhaustion rather than consensus by agreement.