Subject: Re: [Ltru] WG Last Call for draft-ietf-ltru-4645bis-06.txt -- Editorial Comments Only

From: "Doug Ewell" <[email-masked]>
Date: Fri, 17 Oct 2008 21:58:26 -0600

CE Whitehead <cewcathar at hotmail dot com> wrote:

> Doug, I see that ISO 639-3 is all macro-languages and individual 
> languages (http://www.sil.org/ISO639-3/codes.asp); I guess then I just 
> want an explanation of where language subtag elements are assigned a 
> scope value of collection; I see no "collections" listed among the ISO 
> 639-3 codes since 2.3 of the draft mentions this.

OK, I finally see what you are talking about, and you are right -- there 
are a couple of exceptional cases that the text doesn't explain very 
well.

In the current Registry there are two subtags in particular, 'bh' for 
Bihari and 'him' for Himachali.  By definition, based on their type and 
length, these came from ISO 639-1 and 639-2 respectively.  They are not 
encoded in either ISO 639-3 or 639-5, but they are listed on the ISO 
639-3 Web site as "collective" codes.  See:

http://www.sil.org/iso639-3/codes.asp?order=reference_name&letter=b
http://www.sil.org/iso639-3/codes.asp?order=reference_name&letter=h

ISO 639-2 does include code elements for language collections, but they 
aren't formally identified with a special property the way they are in 
639-3.  Instead, 639-2 has a guideline (stated in their FAQ) that "The 
words 'languages' or '(Other)' indicates that a language code is a 
collective one."  Evidently this naming convention was not applied to 
these two code elements, and perhaps that explains why ISO 639-5 failed 
to pick them up as collections.

So to summarize, the last sentence in draft-4645bis-06, Section 2.3, 
paragraph 4, is incorrect or at least misleading:

"Language subtags corresponding to code elements that were identified in 
[ISO639‑3] as representing collection codes, but not listed in 
[ISO639‑5], were also assigned a Scope value of 'collection'."

These language subtags are indeed identified *on the ISO 639-3 Web site* 
as representing collection codes, but I suppose it's not really correct 
to say they are so identified *in ISO 639-3*.  They are assigned in 
639-2, but not identified there as collections, either formally or 
informally.  They are also not encoded in ISO 639-5.

I propose the following replacement for this sentence:

"Existing language subtags corresponding to code elements that were 
identified by the [ISO639‑3] Registration Authority as representing 
collection codes, but not assigned in either [ISO639‑3] or [ISO639‑5], 
were also assigned a Scope value of 'collection'."

Does that solve the problem?

--
Doug Ewell  *  Thornton, 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: Peter Constable <[email-masked]>
Date: Fri, 17 Oct 2008 22:04:25 -0700

From: [email-masked] [mailto:[email-masked]] On Behalf Of Doug Ewell
Sent: Friday, October 17, 2008 8:58 PM

> 639-3 Web site as "collective" codes...

> to pick them up as collections.

This is one of the cases that I asked the JAC to review before ISO 639-3 was published but that they did not review in time. It still hasn't been reviewed. If it is problematic for RFC 4645bis, we should be able to request some expedited action to resolve it.

Peter

---

From: John Cowan <[email-masked]>
Date: Sat, 18 Oct 2008 02:23:57 -0400

> Does that solve the problem?

Yes.

-- 
John Cowan   [email-masked]
    "Mr. Lane, if you ever wish anything that I can do, all you will have
        to do will be to send me a telegram asking and it will be done."
    "Mr. Hearst, if you ever get a telegram from me asking you to do
        anything, you can put the telegram down as a forgery."
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: CE Whitehead <[email-masked]>
Date: Sat, 18 Oct 2008 10:56:39 -0400

Doug, your language is more precise now!  Much less confusing. 

(& Sorry for my asking this change to be made in Section I, the introduction; it is a detail that can be omitted from that section at least. )  

--C. E. Whitehead
[email-masked]

> From: [email-masked]
> To: [email-masked]
> Date: Fri, 17 Oct 2008 21:58:26 -0600
>
> CE Whitehead  wrote:
>
> length, these came from ISO 639-1 and 639-2 respectively.

{I was looking for the codes identified this way but ran out of time online; sorry; I went through the a's and c's and several other letters; not the b's and h's.  My goof.}

> They are not
> to say they are so identified *in ISO 639-3*.

It's partially correct.

> They are assigned in

{Ed. comment:  I think you can say just collections; the "code elements" "were identified by the [ISO639-3] registration authorities as representing collections"; you already have the words, 'code elements'}
> were also assigned a Scope value of 'collection'."

This is more precise.

It reads o.k.  My try:

"Existing language subtags whose code elements were assigned prior to [ISO639-3] or [ISO639-5] and which were identified by the [ISO639-3] Registration Authority as representing collections were assigned a Scope value of 'collection' {even though they are not listed as such in [ISO639-5]}."

Yes.
{NOTE:  Peter Constable's message  suggests that these two codes--[bh] and [him]--identified as collections in ISO639-3, should maybe be identified in ISO639-5 ?? instead--  except that ISO639-3 has already been published and these codes are definitely listed there, as 'collective' so I do not see how that will change now.  If ISO 639-3 can still be modified, then maybe we should, as Peter suggests, get more time instead of making this change to the draft.}
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 18 Oct 2008 11:48:42 -0600

Peter Constable <petercon at microsoft dot com> wrote:

> This is one of the cases that I asked the JAC to review before ISO 
> 639-3 was published but that they did not review in time. It still 
> hasn't been reviewed. If it is problematic for RFC 4645bis, we should 
> be able to request some expedited action to resolve it.

Depends on how you define "problematic."  I did have to make a special 
case to handle it, beyond the automated merging of the 639-3 and 639-5 
code lists and the existing Registry.  But there are already other 
special cases, like changing some of the existing Preferred-Values to 
get rid of chains, and changing grandfathered tags to redundant as 
needed.  I suppose these could be automated too, but then again, so 
could this.

If you're thinking about knocking on the JAC's door, you might inquire 
when the 639-5 site is going to be available, so we can find out about 
updates and find out whether they've fixed problems like this one and 
'car'.  I heard that site was supposed to be ready by September.

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 18 Oct 2008 12:07:21 -0600

CE Whitehead <cewcathar at hotmail dot com> wrote:

> "Existing language subtags whose code elements were assigned prior to 
> [ISO639-3] or [ISO639-5] and which were identified by the [ISO639-3] 
> Registration Authority as representing collections were assigned a 
> Scope value of 'collection' {even though they are not listed as such 
> in [ISO639-5]}."

I have no problem with using your wording, but without the curly braces:

"... a Scope value of 'collection,' even though they are not..."

> {NOTE:  Peter Constable's message  suggests that these two codes--[bh] 
> and [him]--identified as collections in ISO639-3, should maybe be 
> identified in ISO639-5 ?? instead--  except that ISO639-3 has already 
> been published and these codes are definitely listed there, as 
> 'collective' so I do not see how that will change now.  If ISO 639-3 
> can still be modified, then maybe we should, as Peter suggests, get 
> more time instead of making this change to the draft.}

Waiting for changes in 639-5 could take a LONG time, especially since we 
currently have no way to check online to see if and when the changes 
were made.

The codes definitely should be collective and not individual; "Bihari" 
and "Himachali" are blanket terms for the languages spoken in Bihar and 
Himachal Pradesh.  So there is no work for ISO 639-3 to do.

We're in the middle of a two-week Last Call for draft-4645bis.  If we 
can get a commitment from the 639-5 people that they will make *and 
publicize* this change within the next week or two, then I'm not opposed 
to waiting for it.  But any change they make here will simply regularize 
what is currently a special case in the draft; the end result will be 
the same.  So we shouldn't have to worry about making a corrective 
change later on if we just go with this now.

---

From: Peter Constable <[email-masked]>
Date: Tue, 21 Oct 2008 23:33:19 -0700

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Constable
Sent: Friday, October 17, 2008 10:04 PM

>> Bihari and 'him' for Himachali...

> This is one of the cases that I asked the JAC to review before ISO 639-3
> was published but that they did not review in time. It still hasn't been
> reviewed...

Let me give a little more precise detail. In early 2004, I made a list (if I've counted correctly) 93 issues involving 107 different entries in 639-2. I got comments from one JAC participant fairly soon, but then didn't get JAC as a commenting and bringing closure to issues. Over the next couple of years, there were a few occasions in which I needed an immediate decision on one of the issues, and got the JAC to come to consensus, but in terms of the whole I hadn't succeeded in getting closure.

Then, in October 2006, as 639-3 was in its last ballot, the window of opportunity for the JAC to act before 639-3 was published was running out. Three of the 93 items had been explicitly resolved, with 90 left to close. So, I took a different approach. First, I identified 46 that really were not controversial, and considered them to have been tacitly accepted by the absence of any concerns raised. (Most were decisions to deem items to be macrolanguages -- alternatives would have been collection or to narrow denotation to one specific variety.) There were another 6 that really didn't need to be decided before 639-3 was published (e.g. whether mo/mol means the same as ro/ron/rum or not). That left 38 items I wanted decisions on. I broke those into chunks of similar items and started getting the JAC to review one batch at a time. Within a month, I had closure on 19 of those items -- and if you look at the 639-2 change history, you'll see a flurry of changes between 2006-10-25 and 2006-11-22 (http://www.loc.gov/standards/iso639-2/php/code_changes.php).

Now, when I organized those batches of similar items, I chose to leave out any languages of India, having in mind to discuss those last, as they included some of the most complicated cases and so were most likely to end up getting bogged down in inaction. I ended up with 12 issues on which I never got a JAC decision (but would have wanted to) before 639-3 went live:

Language        ID            Proposed change
Bihari      bh/bih      collection
Himachali   him         collection
Rajasthani  raj         macrolanguage
Konkani     kok         macrolanguage
Malay         ms/msa/may  macrolanguage
Marwari     mwr         macrolanguage
Swahili     sw/swa      macrolanguage
Dogri       doi         macrolanguage
Lahnda      lah         macrolanguage
Panjabi     pa/pan      clarify denotation
Tibetan     bo/bod/tib  clarify denotation

After 639-3 was published, the urgency (and in some cases even the opportunity) for discussing these and taking actions went away.

Peter

---

From: Peter Constable <[email-masked]>
Date: Tue, 21 Oct 2008 23:49:52 -0700

From: [email-masked] [mailto:[email-masked]] On Behalf Of Doug Ewell
Sent: Saturday, October 18, 2008 10:49 AM

> 'car'.  I heard that site was supposed to be ready by September.

It's more of an LOC issue than a JAC issue. LOC is working on it, and is aware that it is overdue. They've been delayed for reasons not entirely under their control.

Peter