Addition to ISO 639-3: [lyg]
debbie at ictmarketing.co.uk
Sat Apr 26 10:26:29 CEST 2008
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. However, I believe we have already set
a precedent for adding comments in this way - see GB JE GG and IM.
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.
> -----Original Message-----
> From: ietf-languages-bounces at alvestrand.no
> [mailto:ietf-languages-bounces at alvestrand.no] On Behalf Of Doug Ewell
> Sent: 26 April 2008 05:23
> To: ietf-languages at iana.org
> Subject: Re: Addition to ISO 639-3: [lyg]
> Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:
> >> My overall feeling is that we should accept the narrowing,
> which is
> >> only implicit
> > Agreed. As we follow ISO 639 this is the right decision to
> make IMHO.
> >> (it does not require actual changes to the registry entry
> for 'kha').
> > I don't agree here. I think, as has been done before, that 'kha'
> > should have a comment added to say something like "as of
> [date] this
> > code does not include Lynghgam - see lyg"
> I'm not completely opposed to this, but I'm concerned about
> the precedent it sets for us (mostly Michael and me).
> Basically we would need to examine every new ISO 639-3 code
> element to determine whether it represents a split of an
> existing code element, and create a comment on the existing
> subtag similar to the one proposed here. (Normally when ISO
> 639-3/RA performs a split like this, they retire the original
> and create two new codes; but there is no guarantee that this
> list would be notified personally in the event an existing
> code is narrowed in scope, as was the case here.) How much
> trouble does it cause if we get a batch of 250-plus ISO 639-3
> changes and one of these slips through unnoticed?
> Doug Ewell * Arvada, Colorado, USA * RFC 4645 * UTN #14
> http://www.alvestrand.no/mailman/listinfo/ietf-languages ^
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
More information about the Ietf-languages