W3C home > Mailing lists > Public > spec-prod@w3.org > October to December 2011

Re: References Re: What are the requirements/problems? Re: Working on New Styles for W3C Specifications

From: Marcos Caceres <w3c@marcosc.com>
Date: Thu, 15 Dec 2011 10:08:17 +0000
To: Noah Mendelsohn <nrm@arcanedomain.com>
Cc: Jim Melton <jim.melton@oracle.com>, Bert Bos <bert@w3.org>, Julian Reschke <julian.reschke@gmx.de>, chairs@w3.org, "spec-prod@w3.org" <spec-prod@w3.org>
Message-ID: <F8D38DA8A67F4E3EA470B8D99EE5BAB9@marcosc.com>


On Thursday, 15 December 2011 at 00:09, Noah Mendelsohn wrote:

> 
> 
> On 12/14/2011 5:55 PM, Jim Melton wrote:
> > It is not always the case that the "latest published version" of a
> > referenced document is intended. There are situations in which a specific,
> > dated reference is required, because the document containing the references
> > was written with respect to a specific, dated version of some referenced
> > document. Furthermore, the editors of documents sometimes change from
> > publication to publication, although that is perhaps relevant only if
> > specific, dated versions are required.
> 
> 
> 
> Strong +1.
> 
> I have been in working groups where the choice of referencing "latest" vs. 
> "dated" was the subject of long and subtle debate. In some cases, reference 
> to latest can introduce bugs, including security holes. For example, if the 
> reference is to a character set standard such as ASCII or UNICODE, one can 
> imagine a situation in which a future change to a specification would 
> create security problems, if not outright crash bugs. Conversely, there are 
> good reasons in many cases for an open reference to the "latest".


I agree. My working assumption is that all specs have bugs, but newer versions fix old bugs but introduce new ones. Over time, updated specs may have less bugs and eventually stabilise.

> In any case, the choice of "latest" vs. "dated" must be left to the 
> individual working groups. Even if the W3C were to have guidelines, working 
> groups must have the flexibility to make the case for exceptions in 
> particular situations. Choices like this should >not< be locked into 
> templates or other generic spec production tooling.
> 

I agree: should be up to the editor or group. This is certainly not to be codified. I raise this because, as you saw with Bert's XML file, it excluded both links to the editor's draft and the latest published version (hence only providing the choice to use dated versions).   


-- 
Marcos Caceres
http://datadriven.com.au
Received on Thursday, 15 December 2011 10:08:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:19:18 GMT