Re: I18n comment: rfc3066 or successor

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.

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
> >>>
> >>>
> >
> >
> >

-- 
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:Tex@XenCraft.com
Xen Master                          http://www.i18nGuy.com
                         
XenCraft		            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------

Received on Monday, 23 January 2006 00:01:48 UTC