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
