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 <jungk...@gmail.com>
wrote:
On Sun, Dec 2, 2012 at 11:07 AM, James Robinson <jam...@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
members.
- 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
Chaals
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com
