Subject: Re: [Ltru] Addition to ISO 639-3: [lyg]

From: "Doug Ewell" <[email-masked]>
Date: Sun, 27 Apr 2008 12:05:40 -0600

(moving this topic to LTRU)

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

>>> 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.
>>
>> You'd have to convince the 4645bis author to do this, in the RFC 4646 
>> subtag registry ISO 639-3 subtags such as "lyg" don't exist, and a 
>> kha-comment talking about an unregistered lyg-subtag makes no sense.
>
> Yes this is a problem. The sooner RFC464*bis are published and ISO 
> 639-3 made available the better.  Perhaps we should await the 
> publication of these RFC's before we try to do anything.

I'm not opposed to adding Debbie's comment to the 'kha' subtag in 
draft-4645bis, as long as this is not written into the process.  I'd 
hate to see people scream "process failure" if Michael and I don't catch 
every similar instance in the future.  These are just comments, after 
all, and not normative in any way.

I agree with CE that a comment under 'lyg' seems unnecessary.  People 
who have been using 'kha' to tag Lynghgam may need to be directed to the 
new 'lyg' subtag, but I don't see the purpose in pointing people from 
'lyg' back to 'kha' (except to provide a 639-6-like taxonomy, which I 
assume will be adequately provided by 639-6).  We already can't provide 
a complete and tracked change history, because of the possibility of 
un-deprecating subtags and changing or removing Preferred-Values.

If nobody objects -- and soon, because I'm working on draft-4645bis-05 
today -- I'll add the 'kha' comment to the new Registry contents, 
without comment in the prose.

If this situation with 'kha' and 'lyg' is a big problem, maybe we should 
consider getting clarification from ISO 639-3 on what circumstances will 
cause them to narrow the scope of a subtag, as we feel they have done 
with Khasi.

--
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  ˆ

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

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 28 Apr 2008 09:49:11 -0700

> all, and not normative in any way.

The registration process exists, in part, for people to register information about subtags that they deem useful, interesting, or necessary. It should not be incumbent upon the LSR or anyone else to officially take care of such things in subtags other than the ones they officially have to register. Thus, if (hypothetically) Debbie wanted a comment, it would be up to her to request it. It is not a process failure if the LSR fails to request the change for someone else.

That is, if we were under 4646bis now, Michael/Doug would have an 'lyg' subtag record that they would be responsible for producing (although the process allows anyone to submit the request).

Addison

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization Core WG

Internationalization is not a feature.
It is an architecture.

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 28 Apr 2008 18:19:24 +0100

Doug wrote:

> I'm not opposed to adding Debbie's comment to the 'kha'
> subtag in draft-4645bis, as long as this is not written into
> the process.  I'd hate to see people scream "process failure"
> if Michael and I don't catch every similar instance in the
> future.  These are just comments, after all, and not
> normative in any way.

Thanks. Although I think that this should form part of the formal process.
I think it should be written into the RFC as a "Should" for this type of
situation.

>
> I agree with CE that a comment under 'lyg' seems unnecessary.
>  People who have been using 'kha' to tag Lynghgam may need to
> be directed to the new 'lyg' subtag, but I don't see the
> purpose in pointing people from 'lyg' back to 'kha' (except
> to provide a 639-6-like taxonomy, which I assume will be
> adequately provided by 639-6).  We already can't provide a
> complete and tracked change history, because of the
> possibility of un-deprecating subtags and changing or
> removing Preferred-Values.

Obviously we cannot change what has gone before.  However, my feeling is
that we should look at the use case for 'lyg'.  Let me give you a use case
scenario:

Joe Bloggs is a new employee within Company A; working with a Meta Data
Registry.  He started work a week after 'lyg' was added.   He receives a
request from top management within Company A to find all documents relating
to Lyngngam.  Having searched the LSR for Lyngngam, establishing the correct
subtag to perform a match, he searches his Meta Data Registry for anything
tagged with 'lyg'.  He finds nothing.  Where are the 'lyg' documents that
his top management knows are in his Meta Data Registry?

With a comment field within 'lyg' directing Joe to 'kha' he can do a
secondary match.  With no comment he has no chance of finding the documents
unless he knows enough about the LSR to do a search for comments regarding
'lyg' (which would bring up my proposed comment within 'kha' but only in
this particular instance).

At the moment these comments may or may not be there according to the rules
of the current RFC.  I don't think this is good enough.  We can do better
and I don't think it will cost a lot to do it.  A simple rule that states
"where the meaning of a subtag is narrowed and a new subtag is issued as a
result both subtags should have comment fields denoting the change history".
A simple "watch this page" scenario on the ISO 639-3 change notification
page would assist in the process.

> If nobody objects -- and soon, because I'm working on
> draft-4645bis-05 today -- I'll add the 'kha' comment to the
> new Registry contents, without comment in the prose.
>
> If this situation with 'kha' and 'lyg' is a big problem,
> maybe we should consider getting clarification from ISO 639-3
> on what circumstances will cause them to narrow the scope of
> a subtag, as we feel they have done with Khasi.

A wise move.

Best wishes

Debbie

Debbie Garside
http://www.geolang.com