W3C home > Mailing lists > Public > www-tag@w3.org > April 2012

Re: ACTION-687: Please help me remember what this one is about

From: Thomas Roessler <tlr@w3.org>
Date: Wed, 25 Apr 2012 19:01:46 +0200
Cc: Thomas Roessler <tlr@w3.org>, Larry Masinter <masinter@adobe.com>, "www-tag@w3.org" <www-tag@w3.org>, Ian Jacobs <ij@W3.org>
Message-Id: <1300F2F4-D13C-46DE-95ED-A47BED4794A4@w3.org>
To: Noah Mendelsohn <nrm@arcanedomain.com>
Noah wrote:

> I thought that somewhere in the W3C process was a clause that, put informally, boils down to: "The referent of any normative reference from a W3C draft or recommendation must be at a level of stability that is, at worst, one level flakier than the referring document."

> I can't offhand find where such a rule is set down,

Right, that's the rule we generally stick to.

(And no, I can't find the reference to that one off-hand, either.)

> but Larry's comment seems to be about the general effectiveness of W3C guidelines in this area. It's also a matter of judgement, and maybe something on which we need a ruling, as to when if ever references to IETF IDs from W3C working drafts or Recs would/should be acceptable per such rules.

Two observations:

1. Referencing I-Ds from Working Drafts is a necessity for any joint or coordinated work.  How else should W3C and IETF be able to have APIs and protocols developed in parallel, referencing each other?

2. I don't think anybody has disputed that the reference from a Recommendation to an I-D was a mistake.  Absent ambiguity here, I'm not sure what ruling you'r seeking.

(If anybody was arguing that referencing an I-D from a Rec is a fine thing, then there might indeed be a process question here.)

A different question would be how well we do at enforcing these rules, and whether there are measures to improve those.  Again, I'm not sure whether that's a process question -- it might be a tooling question best asked of those who are revising the toolset we use to produce our specifications.
Received on Wednesday, 25 April 2012 17:01:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:44 UTC