W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: CfC: publish WD of XHR; deadline November 29

From: Glenn Adams <glenn@skynav.com>
Date: Sat, 1 Dec 2012 19:40:05 -0700
Message-ID: <CACQ=j+dMG73qZTMkk5O=EX6VTqDmd2F32_RZQEa8COwM99RqjA@mail.gmail.com>
To: James Robinson <jamesr@google.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Ms2ger <ms2ger@gmail.com>, public-webapps <public-webapps@w3.org>
On Sat, Dec 1, 2012 at 7:07 PM, James Robinson <jamesr@google.com> wrote:

> On Sat, Dec 1, 2012 at 5:54 PM, Glenn Adams <glenn@skynav.com> wrote:
>> On Sat, Dec 1, 2012 at 6:34 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:
>>> On Sat, Dec 1, 2012 at 4:44 PM, Glenn Adams <glenn@skynav.com> wrote:
>>> > On Sat, Dec 1, 2012 at 1:34 PM, Ms2ger <ms2ger@gmail.com> wrote:
>>> >> I object to this publication because of this change:
>>> >>
>>> >> http://dvcs.w3.org/hg/xhr/rev/2341e31323a4
>>> >>
>>> >> pushed with a misleading commit message.
>>> >
>>> > since you don't say what is misleading, and since commit messages are
>>> > irrelevant for W3C process, this  objection is immaterial
>>> Ms2ger objected to the change, not the commit message, so your
>>> objection to the objection is misplaced.
>>> However, the commit message isn't long, so it's not difficult to
>>> puzzle out what ey might be referring to.  In this case, it's the
>>> implication that changing a bunch of normative references from WHATWG
>>> specs to W3C copies of the specs is somehow necessary "according to
>>> pubrules".
>> Then whomever ms2ger is should say so. In any case, there  is no reason
>> to reference a WHATWG document if there is a W3C counterpart.
> Sure there is if the W3C version is stale, as is the case here.  That
> commit replaced a link to http://xhr.spec.whatwg.org/, last updated
> roughly a week ago, with a link to http://www.w3.org/TR/XMLHttpRequest/which is dated January 17th and is missing an entire section (section 6).
>  It also replaced a link to http://fetch.spec.whatwg.org/# with
> http://www.w3.org/TR/cors/# which is similarly out of date by the better
> part of a year and lacking handling for some HTTP status codes.  Every
> single reference updated in this commit changed the document to point to an
> out-of-date and less valuable resource.
> It seems that you, like the author of the commit message, mistakenly think
> it's a goal to replace all links to point to W3C resources even when they
> are strictly worse.  That's not in the W3C pub rules or a good idea.

I didn't suggest this was demanded by pubrules, and indeed, I pointed out
in a prior message that the pub rules do not dictate what documents or

My position w.r.t WHATWG documents is that they should never be referenced
by a W3C document unless there is no other option. Why do I say this?
Because WHATWG documents are never final, at least according their
principals. The W3C should not reference a document that is by definition
never going to reach a final state, at least that is my opinion. Further,
the W3C should not reference a document for which the IPR status is not
sufficiently well defined, again this is my opinion. You or others may

In the cases in point, someone needs to determine if the referenced
documents will continue to move forward in the W3C, and if so, then they
need to be updated according to the W3C Process rules.

[1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0501.html
Received on Sunday, 2 December 2012 02:40:49 UTC

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