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, 16 Dec 2011 10:40:57 +0000
To: ""Martin J. Dürst"" <duerst@it.aoyama.ac.jp>
Cc: Noah Mendelsohn <nrm@arcanedomain.com>, 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: <962EACAA331E4982806C2690C5C0CD17@marcosc.com>

On Friday, December 16, 2011 at 8:47 AM, "Martin J. Dürst" wrote:

> Hello Noah, others,
> On 2011/12/16 0:38, Noah Mendelsohn wrote:
> >  
> >  
> > On 12/15/2011 5:08 AM, Marcos Caceres wrote:
> > > 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.
> >  
> >  
> >  
> > No, not foreseeable and avoidable ones. In many cases. Let's say that
> > specification S(V1) references Unicode(V1). Now Unicode is updated. In
> > many cases it's crucial that users of S >not< start using that
> > specification with Unicode(V2) until the group responsible for S
> > specifies a way of doing so that's secure and interoperable.
> Well, actually wherever possible, it's crucial that specs be written so  
> that there is no need for such spec updates when Unicode is updated. In  
> most cases, that's easily possible. As an example, specs such as XML and  
> HTML allow virtually any Unicode character in content, even if not all  
> characters, and in particular not all recently newly assigned ones, may  
> be perfectly rendered (or even rendered at all).
> That may sometimes need some new ideas, and sometimes it may mean to let  
> go of old ideas. As an example, XML 1.0 for a long time was tied to  
> Unicode 2.0 when it came to element or attribute names and the like.  
> That was because in an SGML + US-ASCII world, having definite and closed  
> rules for the relevant syntactic productions was the norm. But it turned  
> out that that this didn't work very well. It was fixed, first in XML  
> 1.1, and later in XML 1.0, Fifth Edition. Please compare
> http://www.w3.org/TR/REC-xml/#NT-NameStartChar and
> http://www.w3.org/TR/2006/REC-xml-20060816/#NT-Name,
> and have a look at the start of
> http://www.w3.org/TR/REC-xml/#CharClasses
> There is a quite similar example with Internationalized Domain Names.  
> IDNA 2003 was based on Unicode 3.2. IDNA 2008 can be moved from version  
> to version, mostly automatically, but occasionally some manual  
> intervention at predefined entry points is needed.
> > For that
> > reason, it may be appropriate for S(V1) to reference specifically
> > Unicode(V1).
> If that's indeed the case. But as I said above, in particular in the  
> case of Unicode, it's highly desirable to get rid of such versioned  
> references.

I agree. This is exactly what we did for Widgets using the same rationale (we used to point to some version number of Unicode, but then dropped it and always point to the latest). This is what the reference looks like in the Widgets P&C Recommendation Document [1]:   

The Unicode Standard (http://www.unicode.org/versions/latest/).  

Which today redirects to 6.0.0.  

Note that other specifications have moved to dropping versioning themselves: for example, (WHATWG) HTML5 dropped the "5" for the same reason, and widgets dropped "1.0" throughout the whole family, saving everyone the confusion over versioning.  

[1] http://www.w3.org/TR/widgets/#unicode  
Received on Friday, 16 December 2011 11:39:22 UTC

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