Subject: [Ltru] Re: 3 extlang to 1 extlang?

From: "Doug Ewell" <[email-masked]>
Date: Sat, 22 Sep 2007 10:11:07 -0700

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

> Shorter tags are better for RFC 2231 encoded words (that's 2047 plus 
> language tags).  At the moment we have 42 as recommended minimal 
> length.  Without extlang2 and extlang3 we'd get 34.

A lot of "math-out" in this post, but basically Frank's point is that 
limiting the maximum possible tag length (disregarding extensions and 
private-use) is a Good Thing for applications like encoded-word that 
have their own limits.

With the current attitudes toward extlangs, I'm sure that any plan to 
introduce a second-level extlang (xx-yyy-zzz) would be dead on arrival, 
so I'm not opposed to simplifying the ABNF by reducing the number of 
extlang levels to 1.

--
Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

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

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 22 Sep 2007 10:03:42 -0700

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

>> The whole point of the registry is that it makes it unnecessary --  
>> indeed, incorrect -- to look at 639-[123], 3166-1, and 19542 to 
>> determine the referents of codes.
>
> It's not more necessary, and in rare cases related to future 
> "recycled" 3166-1 codes it could be even invalid.

That is one minor potential problem that has been pointed out to us 
before.  It's still conceivable, though less likely than before, that an 
ISO RA or MA could decide to reuse a code element in the face of 
widespread opposition, because there are also people who truly don't 
understand the problems this causes.  Consider the following, from the 
the Wikipedia article "Serbian country codes":

"Also, as SB is historic code for Serbia, it was hinted that the country 
[Serbia] could pursue talks with Solomon Islands. However, it is worth 
noting that since ISO 3166-1 requires that a code is unused for five 
years before it can be re-used, this may not be possible even with the 
consent of the ISO and the previous holder, as users of the standard may 
object."

(This article was reportedly a significant primary source of the 
"hinting" and was more an attempt to influence the ISO 3166 
decision-making process than a disinterested description of the 
situation.)

If an ISO code were to be recycled, or even when one is withdrawn, it 
may no longer be possible to direct users to the ISO standard for 
further information.  But then, the ISO standards don't usually provide 
much supplementary information on the "names" they are encoding anyway.

> RFC 4646 didn't remove the general assumptions about valid 639-[12] 
> language codes.

It was supposed to.  Section 2.2 says:  "The Language Subtag Registry 
maintained by IANA is the source for valid subtags: other standards 
referenced in this section provide the source material for that 
registry."

There's no guarantee that every user will read and understand this 
passage, but there's little more that can be done in an RFC.

> For various reasons I think that's a bad idea, we should not "freeze" 
> info in the registry unless it's strictly necessary to guarantee 
> stability.  The "macrolanguage" concept is more flexible than 
> extlang-prefix relations "frozen" at date C and repeated forever in 
> 4646bis tags.

Wait, are we "freezing" or "baking" if we approve extlangs?  I think 
maybe a culinary "Terms and Definitions" section might be needed after 
all.

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 23 Sep 2007 00:57:35 +0200

Doug Ewell wrote:
 
> basically Frank's point is that limiting the maximum possible tag
> length (disregarding extensions and private-use) is a Good Thing
> for applications like encoded-word that have their own limits.

While we're at it I'd like to get rid of another "anomaly" in the 
ABNF, the "registered language subtag" 5*8ALPHA.  Three reasons:

1 - Length, at the moment we have 3+3*(1+3)=15 as worst case for a 
    language subtag with three extlangs.  My calculations claimed
    that we could reduce this by 8 to 3+(1+3)=7.  Actually that's
    incorrect, we'd arrive at 8 instead of 7 for the 8ALPHA case.

2 - Complexity, there are long explanations in RFC 4646 why this
    "registered language subtag" construct SHOULD NOT be used, it
    is in essence an emergency exit if ISO 639-2 refuses to accept
    a proposed language code following their rules.  IMHO we don't
    need this anymore for 4646bis, because ISO 639-3 will deal with
    any proposed language passing a giggle test.  And where that's
    a matter of timing 4646bis offers variants to fill the gaps.

3 - Identification of isolated subtags, quoting the "known issues"
    paragraph of <http://purl.net/xyzzy/home/ltru/ltru2xml.awk>:
|                If the language subtag review list introduces a
# language subtag with 5-8 characters which clashes with a variant
# subtag these subtags would get the same xml:id resulting in an
# XML syntax error.  In practice it's unlikely that there ever
# will be any IANA language subtag not derived from ISO 936, let
# alone using the same string also for a variant subtag.

Of course I could also fix this script by using different IDs for
language tags and the corresponding IDrefs in prefixes.  But that
would be rather complex, because a Macrolanguage field references
either a language or an extlang.  Likely I'd end up with tons of
dead code relevant only for 5*8ALPHA "registered language subtags",
never used, never tested, and muddying the water.

Another approach could be a decree that any given 5*8ALPHA string
MUST NOT be used to denote a variant and a language in the LSTR,
but then we'd get even more "dead prose" in 4646bis about this
construct.

Therefore I propose to get rid of it, it's unnecessary in 4646bis.
 
> With the current attitudes toward extlangs, I'm sure that any
> plan to introduce a second-level extlang (xx-yyy-zzz) would be
> dead on arrival, so I'm not opposed to simplifying the ABNF by
> reducing the number of extlang levels to 1.

Good.  And the more flexible Macrolanguage: field could in fact
support any number of levels, even more than three, always at the
same state as ISO 639-3.

 Frank