W3C home > Mailing lists > Public > public-w3process@w3.org > August 2014

Re: First Draft of W3C version of URL Spec

From: Sylvain Galineau <galineau@adobe.com>
Date: Thu, 28 Aug 2014 22:03:31 +0000
To: Marcos Caceres <marcos@marcosc.com>
CC: Revising W3C Process Community Group <public-w3process@w3.org>
Message-ID: <0F89A6A4-0F61-4DED-9438-7D9BCD03BF7F@adobe.com>

On Aug 28, 2014, at 11:25 AM, Marcos Caceres <marcos@marcosc.com> wrote:

> thanks, Jonas, for moving this...
> 
> On August 28, 2014 at 1:41:16 PM, Jonas Sicking (jonas@sicking.cc) wrote:
>>> Moving this discussion to public-w3process as it's not of technical  
>> nature and not relevant to the public-webapps list.
> 
> I'm also interested in the rationale here. Every time the W3C has tried to copy/paste specs from the WHATWG it has had significant negative consequences. Those are:
> 
> 1. Developer/implementer confusion - which is authoritative? (telling you right now most implementers work from the WHATWG version, go ask them - and deal with it!). 

If implementers work from WHATWG specs and, as you later argue, W3C has no 'reputation or sense of authority' left I'm not sure who's confused? I suspect you mean the wider authoring community. I agree it is confusing for them. But I suspect it's confusing to the extent one can't easily tell whether they're looking at a forked spec, and what it forks from. Or whether they're dealing with a snapshot or a full-on fork with edits happening in both places. Right? 


> 2. (justified and demonstrable) accusations of plagiarism.
I assume the plagiarism bit comes from specs being copied and the original authors' names being removed. I never understood why that was necessary either. This doesn't seem to be the case here, however.

>   
> 3. W3C copy of specs not being maintained, and falling out of date (despite continuous assurances that this would not happen).

If abandoned, I agree a forked version should disappear. W3C WGs generally need to do a better job of cleaning up obsolete documents, moving them to Notes etc. If they can't manage this diligently for their own specs it should be no surprise forks fall by the wayside too. This needs fixing generally. 

> 4. Extreme polarization in the web community (i.e., this is pissing a lot of community members off) to the point that they are refusing to engage with the W3C. I'm also close to this point, and lots of people in the implementer community feel this way.

(And many of us are also getting tired of the folks who are extremely polarized, to be honest). 

>  
> This seriously has to stop.

Yeah, this needs to come to some resolution. But just like it's awkward for some W3C members to push back against forking while approving the forking of WHATWG specs, it also seems a bit awkward for those of us who support forking to tell W3C it's a horrible thing for them to do. One could well argue W3C forks are especially confusing because it is a standard body with a highly authoritative reputation but then you seem to believe that's no longer the case :) FWIW I think W3C has to be careful about snapshotting/forking others' work *because* it is a standard body with a reputation i.e. it can't fork without causing some real confusion.

As pointed out above, I think it is bad if you can't tell something is a fork and where it comes from; I would again note that is not the case here: the WHATWG version is clearly labeled as the upstream one. 

It'd also be nice to know whether a W3C version is intended as a snapshot - i.e. the W3C TR to a WHATWG ED - or an actual fork with its own separate edits. The former may be annoying but it's not a new problem, at least. The latter would be far more bothersome as it implies a possible interop risk (though that of course assumes some implementers do care to implement the W3C version...)
>  
> 
> The WHATWG needs to be treated as a reputable and authoritative standards organization by the W3C (as it does with the IETF and other consortia). W3C specifications need to be able to cite WHATWG specs without fear of repercussions - or having to enter into some process fight. 
> 
> There should be no reason for the W3C to copy/paste WHATWG specifications.

Well, people obviously believe there is, though I've never been clear on why this needs to happen either. The argument I've heard most often revolves around WHATWG's lack of any patent policy. But by the time W3C grabs a copy of some WHATWG spec it might include IP from non-members. So I'm not sure I understand how we need to worry about IPR and can just copy/paste this stuff but then I'm not a lawyer.

The next most-common rationale I've heard involves a need for regular snapshots. Not sure why this needs error-prone copies either. I believe WHATWG lets you address the version you want through a URL. 

So I think we're in the same boat there.


> The WHATWG already said they are happy to use the W3C's CG license to provide royalty free specs to people. Other models have been proposed - like yearly "lawyer snapshots". If there other legal hurdles, then let's work together with the WHATWG to overcome them without resulting to copy/pasting of WHATWG spec.

Sounds like a good TPAC topic?

> 
> The W3C can't continue to compete on its reputation and false sense of authority - it has none. The W3C has lost control of most of the web platform to the WHATWG already: all the fundamental web specs are firmly in WHATWG control (and it continues to hemorrhage specs to the WHATWG through it's refusal to modernize). If the W3C wants to stay relevant and continue to "lead the Web to its full potential", then it needs to wake up and provide a more *competitive* and *attractive* place to do standards work. 
> 
> Copy pasting is not helping anyone. Please stop it. Pretending the WHATWG is not an authoritative standards organization is only hurting the W3C and wasting everyone's time (and leading to the problems I listed above). Please stop it.  

I don't find some of this rhetoric very helpful either, even though I do understand the frustration behind it. 
> 
> 
> 
> 
Received on Thursday, 28 August 2014 22:04:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:11 UTC