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

I need to clarify one point: I don't mind W3C docs making informative
references to WHATWG docs. For example, I wouldn't mind a W3C doc making a
normative reference to a snapshot of a WHATWG doc that has been republished
in the W3C while making an informative reference to its "living"
counterpart in the WHATWG.

On Sat, Dec 1, 2012 at 7:40 PM, Glenn Adams <glenn@skynav.com> wrote:

>
> 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
> referenced.
>
> 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
> disagree.
>
> 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
>