Subject: [Ltru] zh-hakka (was: Re: RFC 4646 production "grandfathered" considered harmful)

From: "Doug Ewell" <[email-masked]>
Date: Sun, 17 Sep 2006 22:53:40 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> John Cowan wrote:
>
>> How is zh-hakka different from zh-xiang or zh-guoyu (except that the 
>> latter is deprecated)?
>
> zh-xiang etc. are not referenced anywhere.  zh-hakka has a reference 
> from i-hak, it appears in a Preferred-Value field.

I'm not seeing the problem that Frank is seeing at all.

4646 Registry:

    Type: grandfathered
    Tag: i-hak
    Description: Hakka
    Added: 1999-01-31
    Preferred-Value: zh-hakka
    Deprecated: 2000-01-10

    Type: grandfathered
    Tag: zh-hakka
    Description: Hakka
    Added: 1999-12-18

The grandfathered tag "i-hak" is deprecated in favor of the 
grandfathered tag "zh-hakka".

4646bis Registry:

    Type: grandfathered
    Tag: i-hak
    Description: Hakka
    Added: 1999-01-31
    Preferred-Value: zh-hakka
    Deprecated: 2000-01-10

    Type: grandfathered
    Tag: zh-hakka
    Description: Hakka
    Added: 1999-12-18
    Preferred-Value: zh-hak
    Deprecated: 2007-01-01
    Comments: replaced by ISO code hak

    Type: extlang
    Subtag: hak
    Description: Chinese, Hakka
    Added: 2007-01-01
    Prefix: zh

The grandfathered tag "i-hak" is deprecated in favor of the 
grandfathered tag "zh-hakka", which in turn is deprecated by the 
generative tag "zh-hak", composed of subtags "zh" and "hak".

What is irregular or ill-advised about this?

> Similarly zh-cmn appears in the Preferred-Value of zh-guoyu, and at 
> the moment there's no subtag cmn.  A dangling pointer.

4646 Registry:

    Type: grandfathered
    Tag: zh-guoyu
    Description: Mandarin or Standard Chinese
    Added: 1999-12-18
    Preferred-Value: zh-cmn
    Deprecated: 2005-07-15

    Type: grandfathered
    Tag: zh-cmn
    Description: Mandarin Chinese
    Added: 2005-07-15

The grandfathered tag "zh-guoyu" is deprecated in favor of the 
grandfathered tag "zh-cmn".

4646bis Registry:

    Type: grandfathered
    Tag: zh-guoyu
    Description: Mandarin or Standard Chinese
    Added: 1999-12-18
    Preferred-Value: zh-cmn
    Deprecated: 2005-07-15
    Comments: replaced by ISO code cmn

    Type: extlang
    Subtag: cmn
    Description: Chinese, Mandarin
    Added: 2007-01-01
    Prefix: zh

    Type: redundant
    Tag: zh-cmn
    Description: Mandarin Chinese
    Added: 2005-07-15

The grandfathered tag "zh-guoyu" is deprecated in favor of the 
generative tag "zh-cmn", composed of subtags "zh" and "cmn". 
Coincidentally, there is also a redundant tag "zh-cmn" which is 
syntactically and semantically identical to the generative tag "zh-cmn".

What is irregular or ill-advised about this?

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
RFC 4645  *  UTN #14

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 18 Sep 2006 09:08:15 +0200

> I'm not seeing the problem that Frank is seeing at all.

For ALL prefixes, for ALL Suppress-Scripts, and for ALL
Preferred-Values anywhere in the registry ALL subtags of
the corresponding tags (or script subtags in the case of
Suppress-Script) are registered.

Minus one hakka in zh-hakka.  What's so difficult about
this ?  Something that will never again happen under 4646
rules, a very special case.  Line 117 in the registry to
XML script, it had to be "hardwired".   

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 18 Sep 2006 09:08:15 +0200

Frank

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 18 Sep 2006 06:31:42 -0700

Stephane Bortzmeyer <bortzmeyer at nic dot fr> wrote:

> On Mon, Sep 18, 2006 at 09:08:15AM +0200,
> Frank Ellermann <[email-masked]> wrote
> a message of 16 lines which said:
>
>> Preferred-Values anywhere in the registry ALL subtags of the
>> corresponding tags (or script subtags in the case of
> Yes, but it is a consequence of RFC 4646 rules or is it just a
> coincidence?

It's just a coincidence.  There is no restriction that a Preferred-Value 
cannot be a grandfathered tag.

---

From: Addison Phillips <[email-masked]>
Date: Mon, 18 Sep 2006 12:07:45 -0700

> cannot be a grandfathered tag.

It's a coincidence, but one that is desirable. In other words, I think 
it would be a Bad Thing to deprecate some value in favor of a 
grandfathered tag in the post-RFC 4646 era.

In fact, the rules explicitly allow a Preferred-Value to be a tag, if 
the thing being deprecated is a grandfathered item. In 4646bis, for 
example, it says:

--
# For fields of type 'script', 'region', and 'variant', 
'Preferred-Value' contains the subtag of the same 'Type' that is 
preferred for forming the language tag.
# For fields of type 'language' and 'extlang', 'Preferred-Value' 
contains the language production (see Figure 1 (Language Tag ABNF)) that 
is preferred when forming the language tag. This can be simply a 
'language' subtag, or it can be a 'language' subtag followed by an 
extended language sequence.
# For fields of type 'grandfathered' and 'redundant', a canonical 
mapping to a complete language tag.
--

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 19 Sep 2006 01:27:14 +0200

>>> Suppress-Script) are registered.

JFTR, I forgot to mention ALL redundant tags.

>> is it just a coincidence?
> It's just a coincidence.

Not really, a Prefix must consist of registered subtags, and
a Suppress-script must be a registered script subtag.  For a
Redundant tag the name "redundant" suggests that it contains
only registered subtags.

The remaining wiggle room is a Preferred-Value, and Addison
listed:  For script + region + variant it must be a registered
subtag of the same type.  Ditto for language under 4646 rules,
that will be extended to include extlang, but it still must be
a registered language or extlang.

That limits potential "coincidences" to the Preferred-Value of
redundant or grandfathered.  Because the grandfathered zoo is
frozen you'll find that i-hak with Preferred-Value zh-hakka is
the only case.

It's highly unlikely (and no mere coincidence) that i-default,
i-enochian, or i-mingo get a Preferred-Value pointing into the
grandfathered tags.  I daresay impossible.  Also for all other
"not yet" (state 4645bis-00pre) deprecated grandfathered tags.

And I also don't see any remaining redundant tags getting a new
Preferred-Value pointing into the grandfathered tags.  Based
on that the hakka-"coincidence" turns out to be a singularity.

In theory i-default qualifies as the target of a no nonsense
Preferred-Value, but in practise the 4646 rules don't allow it.

Frank

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 18 Sep 2006 23:09:07 -0700

> grandfathered tag in the post-RFC 4646 era.

Of course it would.  Nobody's proposing to do this in the future.  We 
are talking about the situation with "zh-hakka", which became the 
Preferred-Value for "i-hak" (except we didn't call it that) back in the 
RFC 1766 era.  It's not going to be partitioned into language + variant 
(unlike "en-boont") because we know the language is covered by ISO 
639-3.  This situation could not happen again.

> ...

I did cite that.  We know the P-V for deprecated tag "A" must be another 
tag -- the question is whether tag "B" can be a grandfathered tag.  And 
the answer is, of course it can, as long as tag "B" replaced tag "A" 
before the RFC 4646 era.  That is exactly what happened with "zh-hakka".

---

From: Addison Phillips <[email-masked]>
Date: Tue, 19 Sep 2006 08:06:48 -0700

It occurs to me that we should add text in 4646bis forbidding the 
registration of those subtags that would make a grandfathered tag, if 
that tag is deprecated. Rather than regularizing "zh-hakka" (and 
friends), we ought to prevent conflicts with it so that it can rest in 
peace.

Addison