W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: publishing new WD of URL spec

From: Glenn Adams <glenn@skynav.com>
Date: Thu, 11 Sep 2014 00:14:39 +0200
Message-ID: <CACQ=j+d2swd9_tiDnoS7uz3Wxfspu2Bb+dzc_y0SA9i7=dbhNA@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: Arthur Barstow <art.barstow@gmail.com>, public-webapps <public-webapps@w3.org>, "www-tag@w3.org" <www-tag@w3.org>
WHATWG specs are not legitimate for reference by W3C specs. Their IPR
status is indeterminate and they do not follow a consensus process.

On Wed, Sep 10, 2014 at 11:58 PM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> This is a formal objection to the publication of this specification.
>
> 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.
>
> 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.
>
> 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.
>
> 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. 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 [4]. In the category of "these proposals MAY be
> vague or incomplete" [5], I would like the W3C to consider seriously how to
> react to the world wherein standards best serve the web by being living,
> and find some way to get out of the outmoded and bug-encouraging mode of
> thinking that stands behind "stable references."
>
> 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: an
> automated system for ensuring that the latest version of the upstream spec
> is always copied to TR; a blacklisting of outdated snapshots from search
> engines via robots.txt; 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; 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).
>
> [1]: http://wiki.whatwg.org/wiki/TR_strikes_again
> [2]: https://github.com/mozilla/servo/wiki/Relevant-spec-links
> [3]: http://status.modern.ie/
> [4]: http://blog.whatwg.org/make-patent-commitments
> [5]: http://www.w3.org/2014/Process-20140801/#FormalObjection
>
>
> -----Original Message-----
> From: Arthur Barstow [mailto:art.barstow@gmail.com]
> Sent: Wednesday, September 10, 2014 18:40
> To: public-webapps; www-tag@w3.org
> Subject: PSA: publishing new WD of URL spec
>
> [ Sorry for the cross-posting but this is about a joint WD publication
> between WebApps and TAG. ]
>
> This is heads-up (aka PublicServiceAnnoucement) about the intent to
> publish a new WD of the URL spec (on or around Sept 16) using this ED as
> the basis:
>
>    <http://w3ctag.github.io/url/>
>
> As previously agree, and codified in WebApps' current [Charter], the WD
> will be published jointly by WebApps and the TAG.
>
> I realize some people do not support W3C publishing the URL spec, so as
> reminder - as defined in WebApps' off-topic discussion policy
> ([OffTopic]) - if anyone has any _process-type_ comments, concerns, etc.
> about this publication - please send that feedback to the public-w3process
> list [w3process]. Please do _not_ send such feedback to public-webapps nor
> www-tag.
>
> -Thanks, AB
>
> [Charter] <http://www.w3.org/2014/06/webapps-charter.html#liaisons>
> [OffTopic]
> <https://www.w3.org/2008/webapps/wiki/WorkMode#Off-Topic_Discussion_Policy
> >
> [w3process] <http://lists.w3.org/Archives/Public/public-w3process/>
>
>
>
>
>
Received on Wednesday, 10 September 2014 22:15:27 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:16 UTC