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

the tag discussed the general issue of normative references, and I had thought, at least temporarily accepted the resolution that the guidelines in the QA rec would cover the situation. This incident is a reminder that there is not anything in the W3C process to insure QA guidelines are followed, even above the preferences of an editor or a small but vocal subset of working group thinks otherwise: the costs are borne by others not among the eager technicians pushing the latest ideas and held back by stuffy ideas like "stable normative references".

I suggest the tag ask the AB more generally about the process for insuring our resolution affects the rec process. At what point are sppecs required to have stable references, and what are the explicit exception guidelines?

Connected by DROID on Verizon Wireless


-----Original message-----
From: Robin Berjon <robin@berjon.com>
To: Noah Mendelsohn <nrm@arcanedomain.com>
Cc: Thomas Roessler <tlr@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>, Ian Jacobs <ij@w3.org>
Sent: Wed, Apr 25, 2012 20:57:44 GMT+00:00
Subject: Re: ACTION-687: Please help me remember what this one is about

On Apr 25, 2012, at 21:49 , Noah Mendelsohn wrote:
> First of all, can we get links to the exact dated copy of the Rec in question, so that we can all verify what the facts of the "case" are.

Sure: http://www.w3.org/TR/2011/REC-widgets-20110927/.


> On 4/25/2012 3:11 PM, Robin Berjon wrote:
>> I would suspect that this specific case may be defensible. The I-D in question is the best existing documentation for a process that is already implemented pretty much across the board anyway. Documentation of the de facto, however unstable, could justifiably have been considered better than nothing at all.
>
> Perhaps, but I would certainly expect such a reference to be non-normative. Was it in this case?

No. Given that the goal is increased interoperability and that sniffing is a required feature in widget processing making the reference informative would only weaken the requisite conformance level.

> I would also expect that even if it were for some reason allowed, the reference would be accompanied by some explanation of its somewhat unusual status as being best-available rather than stable or community consensus.

Requesting this addition would lead to a long and unhelpful debate about whether there really is a difference between best-available and stable that probably wouldn't come to much resolution. Given that it wouldn't affect conformance, I'm not sure how helpful it would be anyway.

> Further more >if< the reference is to an IETF document for which the link will go 404 after the document expires, then I don't think that would be particularly defensible in a REC (not sure that's the case here, but links from a rec should be to documents that will, with high probability, remain accessible far into the future, IMO.)

If IETF does indeed mint uncool URIs it's certainly a problem, but I would expect that problem to be taken to the IETF. As things stand though, the draft has expired but the link still works.

> Again, all of this will be easier to judge with a dated URI for the Proposed Recommendation in question.

NB: It's not a PR, it's REC. There isn't anything much we can change about it now.


--
Robin Berjon - http://berjon.com/ - @robinberjon