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: Fri, 23 Dec 2011 18:41:52 +0000
To: Noah Mendelsohn <nrm@arcanedomain.com>
Cc: liam@w3.org, "Martin J." <duerst@it.aoyama.ac.jp>, 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: <1F1D6759CD0A49E3A815FC025456979F@marcosc.com>

On Friday, 23 December 2011 at 18:14, Noah Mendelsohn wrote:

> On 12/22/2011 8:09 PM, Marcos Caceres wrote:
> > I think the W3C should mandate that every versioned specification alway
> > have a/latest/ (or similar, like Unicode does) for people who just want
> > the latest Rec of a spec.
> I want to be clear what you're advising. We've been talking about biblios,  
> so let's consider a case where Bibilo B is to reference the specific  
> version RV of evolving specification R.
> * If you are saying that each dated version of R, such as RV, should also  
> include a reference to R (the undated/unversioned link), I agree. I think  
> that's standard practice for W3C TR track documents, no?

In most cases yes, but consider:  


As an example, there is no guarantee that "xmldig-core1" will eventually (when it goes to Rec) replace "xmldig-core". I would like that guarantee.  

Here is another example:  



Ideally, "xml-c14n" should be the document at "xml-c14n11" because it's the latest Rec. There should have been "xml-c14n1", where 1.0 would live. The only reason to that the chain would be broken is if a new version breaks backwards compat with a previous version.  
> * If you're saying that the biblio entry in B must include not only the URI  
> for version RV, but also for R, I strongly disagree.

I don't know, I'm lost in all the Rs and Bs :)   
> Particularly in the  
> case of normative references, the biblio should reference the  
> dated/versioned URI or the latest/undated URI according to whether the  
> intention is to have reference to the specific or the evolving version. If  
> the reference is to RV, then the biblio should >not< in general reference R  
> as well: as noted above, then I think it should be the RV document itself  
> that has links for funding successor versions.
> I couldn't tell which of the conventions above you are advocating.

What SVG does. SVG's short name always points to the latest Rec.  
> (I know IETF has different conventions, and speaking just for myself, I  
> find them unhelpful. There's a priesthood that knows what to do when an  
> IETF URI ending in some number like "-02" disappears from the Web, but  
> ordinary mortals don't.

Yes, this has bitten me once or twice (things at the IETF mysteriously vanish, and then reappear at another URI)… I don't understand the logic there.  
> I'm sure IETF has good reasons with lots of  
> history, but it doesn't work well for me. Nonetheless, I think this should  
> be addressed by IETF, if it is to be addressed at all: I don't think the  
> biblios in W3C documents are the right place to give tutorials or hints on  
> how to deal with IETF document versioning.)

I agree.   
Received on Friday, 23 December 2011 18:42:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:16 UTC