Flagging macrolanguages in the LSR (Was: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis"))

On Tue, Jun 19, 2007 at 02:14:42PM -0700,
 Addison Phillips <addison@yahoo-inc.com> wrote 
 a message of 58 lines which said:

> I take it you're suggesting (or interpreted the proposal) to mean
> that the macrolanguage would contain a pointer or pointers to its
> sublanguages.

No, I was not suggesting it myself but it is a good opportunity to
discuss it.

> %%
> Type: language
> Subtag: zh
> Description: Chinese
> ...
> Encloses: yue,cmn,.....
> %%

It seems reasonable to enumerate a macrolanguage "members "in the
macrolanguage itself. But I see some issues with this proposal:

1) What will be the stability rules for Encloses? Can an extlang be
dropped from a Encloses field? (if advances in linguistics show that
it was wrongly added here, for instance.) And can an extlang be added
to an Encloses? If yes (which seems reasonable), it means that the
macrolanguage entry can change quite often (consider Zapotec with its
dozens of enclosed extlangs).

2) It introduces a redundancy in the registry, an information which
was already there and could be computed from other records. Randy
Presuhn noticed it can be seen as a good thing ("it should be flagged
in its record, rather than requiring it to be computed by examining
all other records"). But more redundancy means more possibilities to
introduce contradictions.

3) 4646bis does not indicate an upper bound for the length of a field
("The content of this field is not restricted, except by [...]
reasonable practical size limitations."). Zapotec's "Encloses:" will
be at least 232 bytes long and sign langauges will be worse. While
there is a long discussion of length issues for tags, it seems there
is none for registry-parsing applications. I suspect that some of them
may have hard-wired limits for field lengths.

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru