Subject: RE: [Ltru] Re: [psg.com #874] propagation of parent organizationdeprecations

From: "Addison Phillips" <[email-masked]>
Date: Thu, 7 Apr 2005 14:45:42 -0700

> Why not simply add the new code, and change the old code to
> "deprecated" with the new code as canonical value ? (= as in 2)

Because we guarantee that once a subtag is canonical it is canonical forever for that meaning.

In my previous note, you'll note that we can separate whether is it deprecated from whether it is canonical. Canonical means that there is another code that should be used. Deprecated merely means "don't use this one (after the date provided)". Canonical is a normative mapping and deprecated is informative by that measure.

Consider NH turning into VU as if it happened a year from now.

Currently (using #2) it is:

%%
Subtag: NH
Canonical: VU
Deprecated: 1980-01-01
%%
Subtag: VU
%%

With the rules I proposed:

%%
Subtag: NH
Deprecated: 2006-01-01
Comment: use VU for Vanuatu
%%
Subtag: VU
%%

With the second, we haven't invalidated anyone's data. But the registry conveys the new value.

As written in John's rules here is what would happen:

%%
Subtag: NH
%%
Subtag: VU
Canonical: NH
Deprecated: 2006-01-01
Comment: use NH for Vanuatu by rule
%%

This is vaguely unsatisfying by comparison.

Now let's consider if some other country got NH assigned to it.

%%
Subtag: NH
Deprecated: 2006-01-01
%%
Subtag: VU
%%
Subtag: 1234
Comment: UN M.49 code, Code NH is used by New Hebrides
%%

Finally, let's consider if VU changed it name again as some future date:

%%
Subtag: NH
Deprecated: 2006-01-01
Comment: use VU
%%
Subtag: VU
Deprecated: 2010-01-01
Comment: use XX
%%
Subtag: XX
%%

Still no one's data is hurt, but there is a trail of bread crumbs to follow.

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Frank Ellermann
> Sent: jeudi 7 avril 2005 14:20
> To: [email-masked]
> Subject: [Ltru] Re: [psg.com #874] propagation of parent
> organizationdeprecations
> 
> John Cowan wrote:
> 
> > 4) When a code is deprecated after Date B, and a replacement
> >    code is provided, the old code remains unchanged in the
> >    registry, and the new code goes into the registry as
> >    deprecated with the canonical form given.
> 
> Why not simply add the new code, and change the old code to
> "deprecated" with the new code as canonical value ? (= as in 2)
> 
>                           Bye, Frank
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Apr 2005 01:35:51 +0200

> canonical forever for that meaning.

That's a dubious idea, "stability" is not the same as "forever
canonical".  Consider the ugly effects for something like RH
or YU instead of new canonical tags ZW or CS.

> we can separate whether is it deprecated from whether it is
> canonical. Canonical means that there is another code that
> should be used. Deprecated merely means "don't use this one
> (after the date provided)".

A deprecated RH or YU with a canonical RH or YU makes no sense.

If something is deprecated it needs a new canonical value where
possible - impossible for SU, simple for DD or RH.  It doesn't
work as expected for the old YU before the split, but it's okay
for the new YU => new CS case.

> Subtag: VU

Yes, that's fine.

> Comment: use VU for Vanuatu

And that's not okay, "comment" isn't readable for machines.
 
> With the second, we haven't invalidated anyone's data.

Both don't invalidate anything, the old NH is still valid, it's
only deprecated.  If NH is later recycled by ISO 3166-1, then
it's better to stay as far as possible away from the old NH.

Human taggers will get it wrong and use the new ISO 3166-1 NH,
no matter what the registry says.  A canonical VU avoids this
foreseeable error.

> This is vaguely unsatisfying by comparison.

This is FUBAR.  Deprecated NH => canonical VU is correct.
 
> let's consider if VU changed it name again as some future
> date:

> Still no one's data is hurt

Until the flood of erroneous NH instead of 1234 begins.  It's
much clearer and simpler to have this "final" constellation:

| Subtag: NH
| Deprecated: 2006-01-01
| Canonical: XX
| %%
| Subtag: VU
| Deprecated: 2010-01-01
| Canonical: XX
| %%
| Subtag: XX
| %%
| Subtag: 1234
| Comment: UN M.49 code, Code NH blocked by New Hebrides

If NH points to VU, and VU to XX, it's also okay.  Bye, Frank

---

From: John Cowan <[email-masked]>
Date: Thu, 7 Apr 2005 23:42:37 -0400

> or YU instead of new canonical tags ZW or CS.

Get used to it.  When the 639-3 languages get included, the whole
notion that most codes are mnemonic is going to go by the board
forever.  There are just too many names.

> it's better to stay as far as possible away from the old NH.

But then all systems have to deal with the identity of (hypothetical)
NH and VU.  By sticking to NH and ignoring the attempted change
(which ISO 639/RA and ISO 15924/RA are pledged not to do), we don't
have that problem.

> Human taggers will get it wrong 

and will use tags like "English".  So it goes.

-- 
After fixing the Y2K bug in an application:     John Cowan
        WELCOME TO <censored>                   [email-masked]
        DATE: MONDAK, JANUARK 1, 1900           http://www.ccil.org/~cowan

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 8 Apr 2005 01:01:32 -0700

I agree with Addison (and not Frank). For stability, you keep the oldest
valid name; otherwise canonicalization for *the same name* may change
between different implementations.

‎Mark