Re: publishing new WD of URL spec

Hi Domenic,

I agree with everything that you have said.

I would like to follow your lead in offering a way forward towards a 
resolution here.

Before I dive into the details, however, I would like to offer a mode of 
work. We can talk and talk and talk about the details until we're all 
blue in the face, but if it's only talking we'll likely run out of 
energy and hit walls because, let's face it, talking about this stuff 
isn't all that interesting.

Instead, I would like for us to work on reaching that amicable situation 
by doing things. That means that instead of freezing everything we ship 
a WD that may not be perfect but improves things, and we do that again, 
and again (and to EDs too where needed) until we're all happy.

Does that sound like a plan?

On 10/09/2014 23:58 , Domenic Denicola wrote:
> My arguments against publishing this specification include that
> copying the spec from the WHATWG is an unnecessarily combative way of
> working with another standards body, especially with regard to the
> URL Standard wherein we/they have been trying hard to address the
> issues of IP coverage and stable references on the W3C's terms. I
> would rather see this talked through and agreement come to regarding
> how the W3C can work to reference WHATWG specs in the same way that
> they reference Ecma or IETF specs.

I agree entirely. I would be happy to be able to reference WHATWG 
specifications, and I think we can get there.

People cite issues with doing that, but I do not believe that they stand 
up to careful examination.

The patent issue is of concern, but it is not without solutions.

The claim that WHATWG doesn't follow a consensus model is simply not 
true (despite what the WHATWG wiki says about that). There are 
exceptions and violations, but overall I see a lot of consensus going on 
there. That's certainly the case for the likes of URL, DOM, Streams...

The bigger part of the problem is social. There is a lot of invidious 
history. We can get to a point at which we get better IP commitments but 
that requires people to act in a collaborative manner.

> On the technical side, I argue that previous efforts to copy WHATWG
> specs, even well-intentioned ones like the DOM, have led to
> out-of-date snapshots permeating the internet, and causing developer
> and implementer confusion. (See links in [1]; see also the contrast
> between one implementer's policies at [2] and another's at [3].) We
> can't even fall back to "never look at TR because it is always out of
> date; use ED instead!" because in the case of e.g. DOM "4", the ED is
> five months out of date.

Here is my proposal to fix that for URL (and if we agree, I'll fix it 
for DOM too):

   - Remove the ED by using any branch other than gh-pages. No ones 
needs that anyway.

   - Include <meta name="robots" content="noindex"> to the TR snapshots.

   - Include a very visible warning in the TR snapshot telling people to 
go to the (real) ED.

I would like to get to a point where we can just reference WHATWG specs 
(it would certainly make my life much easier), but while we figure out a 
way of making TR snapshots roughly functional I'd like to try that now 
(if only so we can get a feel for snapshotting properly).

I *think* that the above proposals, which are implementable right away, 
address your concerns. WDYT?

In addition to the above I would like, as we might have to stick with 
the TR snapshotting for a little while until we figure out a better way, 
to include WHATWG co-branding on the TR version. I can't commit to doing 
that immediately as it's something I need buy-in for, but there's 
precedent (http://www.w3.org/TR/2010/REC-webcgm21-20100301/).

> I acknowledge that Dan is going to great lengths to make sure that
> this copying is done "right", insofar as it can be. E.g., he is
> copying not plagiarizing; he is stating that he wants feedback to
> flow through the upstream version instead of diverging; and he says
> that he will add more clear signposting to the document to help
> direct implementers and developers to the upstream version. However,
> I think this plan is merely a band-aid on a larger problem, akin to
> feeding the W3C's spec-copying addiction with a nicotine patch
> instead of a full-on cancer stick. An improvement, but I'd really
> prefer we break the addiction entirely.

Agreed, but to thread your metaphor there's a reason you have 12-step 
programmes and going cold turkey is considered a bad idea (in fact it 
can be fatal in some addictions). I say let's do this in an n-steps way.

> There are a number of remedies that would address this formal
> objection. The most preferable would be for the W3C to work amicably
> with the WHATWG to figure out a way to treat them and their specs as
> legitimate, instead of constantly copying them.

+1. I would like that discussion to:

   - be in public
   - not be on a technical list
   - not be on a generic process list (because it should be focused)
   - be strict about banning trolls

If you agree that's something we ought to do, I'm happy to set up a 
place. It can be GH issues if you want.

> This could include
> e.g. issuing a call to the AC reps in the webapps working group to
> commit to patent protection via the WHATWG's patent mechanism

I think that patent mechanism is suboptimal and we could actually get a 
much better result using a WG's patent mechanism. We just have to figure 
out a way of making this work through good faith collaboration.

> An alternate way of addressing the formal objection would be outline
> a very clear process for avoiding the dangers that have cropped up in
> previous WHATWG copies. This would include, among other things:

I hope my proposal above can help lift this objection so we can move 
forward. But there's more, too.

> an automated system for ensuring that the latest version of the
> upstream spec is always copied to TR;

We're working on that. There is an upcoming "new publication workflow" 
that can do exactly that. We're hoping to have a demo to show at TPAC. 
Some of the bricks are already in good shape. I know that Tab was 
looking into having every single commit he makes to his CSS specs cause 
a TR WD publication.

> a blacklisting of outdated snapshots from search engines via
> robots.txt;

You probably don't want to use robots.txt for that because you don't 
want crawlers to have to download a 2MB robots.txt just to get started.

But there are alternatives like <meta name=robots> and X-Robots-Tag. 
We're looking into applying the latter to all dated TRs (as a start); we 
can *immediately* start applying the former to URL (and in fact just 
that would IMHO be a good reason to publish this WD because it would get 
to replace the 2012 thing that's there).

> some way of dealing with the fact
> that webapps patent commitments will be made to an outdated snapshot,
> but that snapshot should not be given any prominence for implementers
> or authors visiting the W3C website;

That's longer term to do completely right, but we can at least have a 
big fat warning.

> and a public acknowledgement
> that implementers should not look at any outdated snapshots such as
> CR (so, the normal "call for implementations" would have to be
> modified, so we don't get ridiculous situations like HTML 5.0 is
> currently undergoing where you call for implementations of a spec
> that is multiple years behind what implementations actually need to
> implement for interoperability).

I'm happy to ask to change the "Call for Implementations" to something 
else, but that will require some time.

So. Do you think that can make for a good starting point?

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Thursday, 11 September 2014 13:01:30 UTC