Subject: [Ltru] Re: Process for creating 4646bis Registry

From: "Doug Ewell" <[email-masked]>
Date: Sun, 17 Sep 2006 16:30:22 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

>> The new inputs to the Registry are the ISO/FDIS 639-3 online code 
>> tables.
>
> For the drafts before Last Call.  For the registry it should be the 
> then existing ISO 639-3:2007.

Of course.

>> the subtag "gd" currently has the descriptions "Gaelic" and "Scottish 
>> Gaelic"; the new description "Gaelic (Scots)" from 639-3 will be 
>> added.
>
> As Randy and Debbie wanted it.  You had convinced me that replacing 
> xxxx by xxxx (yyyy) instead of adding it might be okay, but for a 
> first draft any consistent rule goes, we know that it's an open issue.

I had assumed that keeping all the old Descriptions was the hum of the 
group.  We don't seem to be using the issue tracking tool this time, and 
I haven't seen the co-chairs declare consensus on anything yet.  I'm 
trying to gauge consensus myself, and we know how dangerous it can be 
when individual members start doing that.

>> No existing Description fields are changed or deleted.
>
> ACK, that's KISS, please note it explicitly.

I just did.  :-)

[extlangs]
> It's another open issue, compare 
> http://permalink.gmane.org/gmane.ietf.ltru/5420
> For the first draft it's fine, let's look at the output, and then 
> decide if we really like this "macrolanguage" cruft.  The job of 
> 4646bis is to define language tags, not to sanction the POVs of its 
> sources, for that folks should read these sources, not the registry.

Again, there is no ticket and no consensus or hum declared by the 
co-chairs.  We'd better decide this pivotal question soon.  I have 13 
days left to submit a first draft and I will be out of town for four of 
them.

>> zh-hakka   -> zh-hak
>
> Resulting in i-hak -> zh-hakka -> zh-hak (JFTR, we have to eat our dog 
> food)

Correct.  The Registry points "i-hak" to "zh-hakka" and points 
"zh-hakka" to "zh-hak", and validating processors that automatically 
"correct" deprecated tags and subtags to their preferred brethren will 
need to correct "i-hak" directly to "zh-hak".

>> zh-min     -> (no Preferred-Value, just deprecated)
>
> That has to be justified explicitly in prose, as an exception.

Does it?  The Preferred-Values for the others are explicitly listed to 
show how the tags were mapped.  The judgment of the WG is involved, 
although I think in these cases it will be unassailable.  In the case of 
"zh-min" the judgment of the WG is that (a) the tag is deprecated 
because it doesn't refer to a real language and (b) there is no 
Preferred-Value because no alternative tagging possibility exists for 
this non-language.

>> http://users.adelphia.net/~dewell/lstreg-4646bis.txt
>
> Thanks, quick check with the W3C validator (8167 records): One known 
> yi-latn (lower case L) error, anything else okay.

It's not an error, as I said before.  Case is not significant in RFC { 
1766, 3066, 4646, 4646bis } language tags.  There happen to be 
conventions for casing, and the Registry uses those conventions, but 
they are not normative.  IMHO it would be more of an error if we 
"corrected" the case of a previously registered tag; the whole point of 
keeping redundant tags in the Registry is to preserve them in a 
museum-like setting.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
RFC 4645  *  UTN #14 

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

---

From: John Cowan <[email-masked]>
Date: Sun, 17 Sep 2006 19:36:45 -0400

> Preferred-Value because no alternative tagging possibility exists for 

It's a language collection in any case, encompassing 'mnp', 'cdo', 'nan',
and 'czo', and therefore should be deprecated for the same reasons
as the 639-2 collection subtags.

-- 
Normally I can handle panic attacks on my own;   John Cowan <[email-masked]>
but panic is, at the moment, a way of life.      http://www.ccil.org/~cowan

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 18 Sep 2006 08:31:48 +0200

Doug Ewell wrote:

> I'm trying to gauge consensus myself, and we know how
> dangerous it can be when individual members start doing that.

That's editorial freedom, if we don't like the result we can
disccuss it.

 [macrolanguage]
> Again, there is no ticket and no consensus or hum declared by
> the co-chairs.

Yes, that's what I meant.

> We'd better decide this pivotal question soon.

For the initial draft stick to your choice, I only wanted to
mention that it's still an open issue from my POV, it's also
related to the new Preferred-Value / Deprecated rule.  Do we
go with 639-2 if possible, or stick to the extlang notation
for a language once it's in, no matter what 639-2 says later ?

> Does it?  The Preferred-Values for the others are explicitly
> listed to show how the tags were mapped.  The judgment of the
> WG is involved, although I think in these cases it will be
> unassailable.  In the case of "zh-min" the judgment of the WG
> is that (a) the tag is deprecated because it doesn't refer to
> a real language and (b) there is no Preferred-Value because
> no alternative tagging possibility exists for this
> non-language.

Yes, and that has to be noted for readers of 4645bis, they've
no clue how that happened, because it's not obviously triggered
by the 639-3 input.

 [yi-latn]
> Case is not significant in RFC { 1766, 3066, 4646, 4646bis }
> language tags.  There happen to be conventions for casing,
> and the Registry uses those conventions, but they are not
> normative.

In another message I've quoted MUSTard, but admittedly that
was about Script records, not directly for all script subtags
elsewhere.

It's just inconsistent, I stumbled over it with those XML IDs.
The only script subtag not using titlecase, and the tag claims
to be redundant, not irregular grandfathered garbage.

> IMHO it would be more of an error if we "corrected" the case
> of a previously registered tag; the whole point of keeping
> redundant tags in the Registry is to preserve them in a
> museum-like setting.

The museum survives it if one yi-latn is fixed to yi-Latn. :-)

Frank

---

From: Martin Duerst <[email-masked]>
Date: Tue, 19 Sep 2006 22:33:34 +0900

>That's editorial freedom, if we don't like the result we can

[co-chair hat on] Yes indeed.

>For the initial draft stick to your choice,

[co-chair hat on] Yes, please. It's easier to discuss
an actual draft (or potentially some data hanging off
an actual draft but verifiably so) than some proposals
in emails.

>The museum survives it if one yi-latn is fixed to yi-Latn. :-)

[co-chair hat off]
I agree with Frank here. Somebody had to be the first to come up
with the idea of using XML idrefs for cross-checking, and unfortunately,
it didn't happen before RFC 464x. And because case is officially and
completely irrelevant, I don't see a point in the 'museum' preserving it.
And for historians, http://www.iana.org/assignments/language-tags
is still online at the moment, and our mails serve as another
witness to that specific bit of language tag history.

Regards,   Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]