Anomaly in upcoming registry

[Mark Davis ⌛]

Good point; the target for 639-1/2 is different, and the threshold for
deprecation is different. And given this conversation, I think it is pretty
clear that we should un-deprecate sh in the registry; we are following 639-3
in not being restrictive about the codes we add (understatement) to the
registry, they considered the issue of deprecating hbs (=sh) and decided not
to, so we should follow their lead.

Mark


On Mon, Jun 29, 2009 at 13:22, John Cowan <cowan at ccil.org> wrote:

> Mark Davis â?? scripsit:
>
> > hbs = sh, yet
> > hbs is not Deprecated, and
> > sh is Deprecated
>
> It's actually worse than that.  hbs in 639-2 is deprecated ("retired"),
> but hbs in 639-3 is not deprecated.
>
> > We could take ISO 639-3 as superseding 639-1 on the issue of deprecation,
> > and I think that would be the right thing to do. However, it would be
> > cleaner yet if ISO 639-1 were to un-deprecate sh, so that it was
> consistent
> > with ISO 639-3.
>
> For "639-1" read "639-1 and 639-2".  But there's a policy question here:
> coding a language in -1 or -2 is a policy decision, not merely a technical
> one: it involves an explicit value judgement on which languages are
> considered
> important enough to get -1 codes or membership in the -2 set.  The various
> RAs
> reserve the right, it seems to me, to change their minds about this (as we
> reserve the right to ignore it when they remove codes).
>
> --
> My corporate data's a mess!                     John Cowan
> It's all semi-structured, no less.              http://www.ccil.org/~cowan<http://www.ccil.org/%7Ecowan>
>    But I'll be carefree                        cowan at ccil.org
>    Using XSLT
> On an XML DBMS.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20090629/b507636f/attachment.htm