Addition to ISO 639-3: [lyg]

[Doug Ewell]

Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:

> I honestly cannot see that the ISO 639-3 MA will be making many 
> changes and certainly not bulk changes at this stage.  I think it is 
> pretty safe to say that changes would be introduced fairly piecemeal 
> given that each one is generally discussed within the JAC.

The 2007 series of changes to ISO 639-3 involved 247 change requests 
that were initally approved, resulting in 383 changes to the code set, 
plus an additional 10 change requests that were approved later and 
resulted in about 14 more changes.  This is over a period of one year, 
so it represents an average of about one change per day.  I am certain 
the amount of churn will diminish over time, probably to a trickle, but 
it's not there yet.

> However, I believe we have already set a precedent for adding comments 
> in this way - see GB JE GG and IM.

I have little or no problem with that precedent for ISO 3166-1, which is 
a much more stable code set than ISO 639-3 simply by the nature of 
representing ~240 countries as opposed to ~7700 languages.  Changes to 
3166-1 tend to be announced one or two at a time, making it much easier 
to spot a case such as GB that calls for a special comment.

> I think for a coding system to be truly backwardly compatible we must 
> log the changes to assist users in ascertaining the history.  In this 
> instance I would like to see kha with the comment as mentioned 
> previously and also, if possible, a comment on lyg saying "see also 
> kha".  Taken with the change/registration date, this then provides a 
> complete and tracked change history within the registry.

If this situation is duly reported to the ietf-languages list -- that 
code element Y is being split off from existing code element X, and that 
X is therefore implicitly narrowed in scope -- then I'm fine with it. 
If I or Michael or others are required to detect this situation on our 
own, it will be a lot more problematic.

I should note that this particular situation doesn't seem to come up 
very often with ISO 639-3.  The normal procedure seems to be to withdraw 
X, and add Y for the newly split-off language and also add Z for the 
concept of "X minus Y."  (See what was done with Rajbanshi, for 
example.)  In this case our job is easier: we add Y and Z and we 
deprecate X, probably with a Preferred-Value of Z.  The problem is 
picking the Lyngngam needle out of a haystack of almost 400 changes. 
(Sorry for the blatantly "en-US" metaphor.)

--
Doug Ewell  *  Arvada, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ