- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Fri, 16 Dec 2011 17:47:13 +0900
- To: Noah Mendelsohn <nrm@arcanedomain.com>
- CC: Marcos Caceres <w3c@marcosc.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>
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. Regards, Martin.
Received on Friday, 16 December 2011 08:50:21 UTC