- From: Felix Sasaki <fsasaki@w3.org>
- Date: Mon, 23 Jan 2006 11:46:38 +0900
- To: "Tex Texin" <tex@xencraft.com>, "Mark Davis" <mark.davis@icu-project.org>
- Cc: ishida@w3.org, www-style@w3.org, public-i18n-core@w3.org
Hi Tex, all, A comment below. On Mon, 23 Jan 2006 09:01:23 +0900, Tex Texin <tex@xencraft.com> wrote: > > Mark, > > Although I disagreed with the approach taken that has nothing to do with > my > comments. > > As a co-author of the new RFCs, you are clear on the changes and how you > intended for implementation to go forward and how users should treat the > existing standards and extend them to use the new features. > > But that vision is not clear to others (primarily because they don't have > the time and experience yet with the new standards, but potentially > because > of alternative viewpoints). The W3C specifications describe specific > behaviors which should be updated now, for the same reasons that you and > Addison needed to address Matching. > > If the W3C standards just add "and its successors" than it becomes > ambiguous > as to whether that includes the matching guidelines or not. (At least to > me, > since I consider the matching, registry and new 3066bis a "family" of > related and integrated standards.) > Implementers need clarity as to what is expected. > > Since most of the W3C specs explicitly declare the matching rules > (truncation), they should at least consider updating to the new > guidelines. > For consistency across the web, it would be good for the W3C to have a > policy as to how the standards should adapt. (Follow the matching rfc or > stick with truncation.) > > I was not saying the W3C should not move to the new spec. I was saying we > should be more precise than simply adding "and its successors". > > To make a concrete and constructive suggestion, perhaps the W3C i18n > group > should review the many W3C references to rfc 3066 and offer a more > elaborate > guideline for the W3C spec writers to follow when updating their > specifications. > > With respect to the differences in behavior, if you are saying that the > W3C > should not adopt the new matching rules, then perhaps we need a W3C note > or > other guidelines recommending how implementers should address the likely > issues. > Should browsers move to using zh-Hant or zh-Hant-TW in accept-language or > always offer those forms as well as zh-TW? > Should web servers offer both zh-TW and zh-Hant? > > While the practical combinations and solutions (for the many cases > besides > traditional chinese) are clear to some of us in the i18n field, it is > not so > clear to others. > And as the identifiers move down into programming layers (such as CSS > selectors) then the lack of precision becomes more costly to > implementors. > > Some guidelines for specifications writers are called for, to insure > clarity > and consistency across the W3C and for interoperability with IETF and > other > users of RFC 3066. Maybe you don't know - but FYI: i18n core id developing such a document, which I am editing, see http://www.w3.org/International/core/langtags/ . - Among other reaons - since Addison had to leave, this work has not made much progress in the last year. But it will do. Regards, Felix. > > I would rather not get into an extended debate over this. I am > comfortable > with the CSS group deciding after reviewing the issue what is best for > CSS. > I hope the I18n WG will also consider and provide more careful guidance > now. > > tex > > > Mark Davis wrote: >> >> I disagree. 3066bis does not "introduce incompatibilities": scripts >> already occur in 3066 language tags. The matching document is a red >> herring. While useful, it does not replace any normative part of 3066. >> And one of the main matching techniques in it is truncation. >> >> Tex, I know that you disagree with the approach taken in 3066bis (I know >> the feeling; I disagreed with the Unicode addition of the math letters), >> but it's time to move on. >> >> Mark >> >> Tex Texin wrote: >> >> >I do not think that adding "and its successors" is a good idea in the >> case >> >of 3066. >> > >> >The new standard introduces incompatibilities by inserting scripts in >> >between languages and regions. >> >A separate RFC is proposed to define matching rules to help in >> resolving >> >these problems. >> >The W3C should carefully assess the impact on W3C standards of moving >> to the >> >new model of language identification. >> >The standards would also need to consider taking on the new matching >> rules, >> >as until now the matching rules were defined in the individual W3c >> >specifications. >> >e.g. http://www.w3.org/TR/html401/struct/dirlang.html#h-8.1.3 >> >http://www.w3.org/TR/CSS21/selector.html#lang >> > >> >et al. >> >The general rule has been simple truncation, which will now give >> different >> >behaviors when language tags are changed. >> > >> >In cases where web standards say the identifier can be anything, and >> 3066 is >> >only recommended, web applications that use other types of identifiers >> may >> >fail if the matching rules are changed. >> > >> >The W3C should take a more thoughtful and determined approach to >> adopting or >> >adapting to the changes in the RFC 3066 series. >> > >> >The standards that already say "and its successors" need to review the >> >impact of using the new format while maintaining the old matching >> rules. >> >(e.g. css 2.1) >> > >> >tex >> > >> > >> >ishida@w3.org wrote: >> > >> > >> >>Comment from the i18n review of: >> >>http://www.w3.org/TR/2005/WD-css3-selectors-20051215/ >> >> >> >>Comment 8 >> >>At http://www.w3.org/International/reviews/0601-css3-selectors/ >> >>Editorial/substantive: S >> >>Location in reviewed document: >> >>Sec. 6.3.1 >> [http://www.w3.org/TR/2005/WD-css3-selectors-20051215/#attribute-representation] >> >> >> >>Comment: >> >>"as described in RFC 3066 ([RFC3066])" >> >> >> >>Recommend 'as described in RFC 3066 ([RFC3066]) or its successor'. >> >> >> >>Note that its successor is currently only awaiting the IETF editor to >> assign an RFC number, but has been approved by the IETF to succeed >> RFC3066. Note also that it will allow for additional subcode values, >> such as script identifiers. >> >> >> >> >> >> >> >>>From: Daniel Glazman >> >>>[mailto:daniel.glazman@disruptive-innovations.com] >> >>>Sent: 20 January 2006 16:00 >> >>> >> >>> >> >>>#8 ok >> >>> >> >>> >> > >> > >> > >
Received on Monday, 23 January 2006 02:46:59 UTC