Re: I18n comment: rfc3066 or successor

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