Re: [Ltru] Last open item

["Mark Davis" <mark.davis at icu-project.org>]

> we will find ourselves in the situation that a tag found to be OK
> be a validating processor will suddenly become not OK

That is a red herring. There appears to be a fundamental misperception here. The key issue is that canonical form is NOT the same as is valid, and never has been. Moreover:

1. The canonical form is not, and never has been "stable" in the sense you mean. Any time a subtag is deprecated in favor of another, we make the change, which will change the canonical form. True of our process before, and still true in the latest draft.

2. However, the key notion of stability that we have striven for is that once a tag is valid, it will always stay valid. That is true even if the canonical form changes.

3. This drives the main stabilizing principle in BCP 47, which is that once in the registry, we never change the meaning of a subtag in a way that would narrow the denotation of a tag (or change it completely, like CS was handled by ISO). THAT is the area where we stabilize the ISO codes, and where we do not accept changes from ISO.

If you have a math bent, think of it this way. The domain of valid tags is partitioned into equivalence classes. Each equivalence class has one distinguished member, the canonical form. Over time, only certain changes are allowed:

• Tags never disappear (each of the tags, once valid, will always remain valid).
• New tags and equivalence classes may be added.
• The canonical form for a given class may change, but the old canonical form remains valid and remains the same in meaning as the new one.
• Equivalence classes may grow, and may merge (unlikly but possible), but will never split.
  

Mark

On Tue, Apr 15, 2008 at 9:42 AM, Randy Presuhn <randy_presuhn at mindspring.com> wrote:

Hi -

As a technical contributor...

> From: "John Cowan" <cowan at ccil.org>
> To: "Randy Presuhn" <randy_presuhn at mindspring.com>
> Cc: "LTRU Working Group" <ltru at ietf.org>

> Sent: Tuesday, April 15, 2008 11:04 AM

> Subject: Re: [Ltru] Last open item
...

> Stability in the preferred value isn't the sort of stability that we
> can either expect or preserve, particularly in ISO 3166 code elements.
> What we can and do stabilize is the meaning of subtags: if a source
> standard attempts to assign a code element to a different meaning than
> it once had, we provide a replacement subtag instead of reusing that
> code element.
>
> Countries will go on changing their names, and 3166/MA (in accordance
> with its mandate) will change their codes accordingly;

Strongly agree, but....

> in order not to
> get out of sync with the rest of the code-using world, we need to track
> those changes insofar as possible.

...

Strongly disagree.

One of the motivations for the formation of this working group was to provide
a way to insulate language tags from what was perceived as excessive instability
in some of the code sources.  As I see it, stability, particularly the stability of
the canonical form of a language tag, is dramatically more important than
staying in sync with other uses of codes coming from the standards we used
to initially populate our registry.  After all, if we're just going to blindly track
the ISO code du jour for every little piece of dirt, there's really little point
to even bothering to put these things in our registry.  If consistency with
other uses of those source specifications trumps stability as a consideration,
then we should throw out our current procedures and registry, just say "see
ISO registry mumble for these codes", and limit our registry and procedures
exclusively to codes for things that ISO hasn't coded.

Otherwise, we will find ourselves in the situation that a tag found to be OK
be a validating processor will suddenly become not OK.  That's simply
not acceptable.

Randy

_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru

-- 
Mark
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru