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

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

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Mon, 03 Dec 2012 13:44:36 +0100
To: "James Robinson" <jamesr@google.com>, "Glenn Adams" <glenn@skynav.com>, Art.Barstow@nokia.com, schepers@w3.org, public-webapps <public-webapps@w3.org>, "Jungkee Song" <jungkees@gmail.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Ms2ger <ms2ger@gmail.com>
Message-ID: <op.woqq0mf7y3oazb@chaals.local>
Just a reminder: this group is a forum for discussion of technical  
specifications, and follows the existing W3C process. Discussion of what  
process *should* be is off topic here.

On Sun, 02 Dec 2012 12:07:20 +0100, Jungkee Song <jungkees@gmail.com>  

> On Sun, Dec 2, 2012 at 11:07 AM, James Robinson <jamesr@google.com>
>> Sure there is if the W3C version is stale, as is the case here.
> I don't think it's a technical issue to discuss.

Right. Although there are technical aspects to the discussion, it is a  
process issue.

> There should be corresponding publication rules.

We could hassle W3C into updating pubrules so it is clear. I have take the  
action item.

> Art, Charles, Doug,
> Can you help clarifying which links we have to use?

By longstanding practice W3C specifications point where possible to  
references where W3C provides change control, its own guarantee of  
permanence, and its patent policy. General practice is to point to stable  
documents in normative references (e.g. the latest /TR version of  
something), allowing informative references to more or less anything you  
think is interesting.

Until people started playing politics to the point of trying to usurp  
change control through parallel references it seems nobody was terribly  
worried about this. The requirement isn't documented in pubrules last I  
looked, but by process W3C could change that with 10 minutes of work.

I am not even sure that the rationale is clearly documented in any one  
place at the moment. Like the rest of W3C it has developed over a couple  
of decades.

 From my understanding reasons for the practice include the following:
  - W3C aims to provide stable specifications that can be used as  
references which won't change. This is a general underpinning of its  
policy for specifications published as "TR" documents. Making a normative  
reference to an unstable document obviously defeats this purpose.
  - Since 2005 W3C patent commitments are given by W3C participants to the  
work of W3C working groups. Unstable documents that from time to time  
have, or had, more or less equivalent content, are not a replacement for  
those who care about W3C's IPR policy - which includes people far beyond  
the scope of W3C's own membership. Although WHAT-WG is a Community Group,  
its "living standard" model has explicitly disavowed making a final  
specification. This seriously limits patent commitment even from its own  
  - A couple of years ago, W3C was granted PAS submission status, after  
applying for this at the urging of many of its members and of non-member  
consumers of its specifications. This relies on lots of things, but one of  
them is a certain clarity of process. ISO accepted W3C's process. I don't  
know if they would be prepared to accept that of the WHAT-WG. I don't even  
know anyone who cares enough to find out. In the meantime, I suspect this  
is another reason not to make normative references to the WHAT-WG's work  
and in particular to unstable documents.

> In the proposed version, I've changed the links to the following specs:
> - [CORS], [DOM], [DOMPS], [HTML] from the WHATWG version to the latest
> W3C TR doc.
> - [FILEAPI], [PROGRESSEVENTS], [WEBIDL] from the latest W3C ED to the
> latest W3C TR doc.

I think that was reasonable. If any of those documents don't carry a link  
to their W3C editors' drafts, it might be useful to also provide them as  
an *informative* reference.

>> 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).
> This change does not affect any links in the result doc, and in fact
> this proposed publication will reduce the gap.
> The proposed WD is aligned with the WHATWG version except:
> - Progress Events is not merged but staying as a separate spec.

Seems reasonable. As I said in one-on-one conversation at TPAC (and maybe  
repeated for minutes - I forget), I would prefer not to merge these.

If this is controversial we can raise an issue on it.

> - Streams API is deferred to next version.

You mean next version of XHR, or next draft of this spec? Either way, I  
don't see that this should stop publication.

> - The last three commits (Nov 22) in WHATWG has not been incorporated  
> yet.

We're publishing a Working Draft. And we are happy to produce a stabilised  
version and work on a new one. We want better specs, but making perfection  
the enemy of getting a spec good enough to use is not a goal.

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

The claim that this is *strictly* worse relies on a particular restriction  
of use cases.

>> That's not in the W3C pub rules or a good idea.

It isn't written there, although it has been applied for as long as I can  
remember (which stretches back to before "pubrules" was a document). To  
the extent W3C thinks this should apply, they should indeed write it in  
there, since it has recently become contentious.

Pubrules doesn't, as far as I know, prohibit "f-bombs" in specs. W3C  
working group members, including editors, are expected to be socially  
competent adults, which is a catch-all for what would otherwise be an  
endless set of statements like "people who know not to use the 'f word' in  
a spec even without a written rule". (If I recall correctly this is in  
section 3.1 of the process document. It certainly isn't worth looking up).

It is probably worth yet more discussion. It turns out that at least some  
W3C members consider this a live issue. But the membership, perhaps  
because it is broader than people in this conversation or even this group,  
tend to take a broader view of who needs and uses specs which leads to  
accepting a wider range of use cases.

This in turn means that while the costs of W3C's approach are actually  
understood, the existing ("legacy?") consensus of the members has been  
that it is a price worth paying.

And so long as that is the case, this group is a forum for technical  
discussion, and follows the existing W3C process. If you want to play W3C  
politics, members have an obvious forum - talk to your AC rep. Note that  
there is also a Community Group where W3C process and practise is the  
topic, and anyone can contribute. That gets the attention of the editor of  
the W3C process document (me), the Advisory Board (who are responsible for  
the process document and advise W3C on what should be looked at as best  
practice), and the CEO of the W3C, among others.

for the chairs


Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com
Received on Monday, 3 December 2012 12:45:18 UTC

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