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

[Addison Phillips <[e-mail]>]

Stephane Bortzmeyer wrote:
> 
> 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? 

It's informative and thus could be changed. However, extlangs are 
permanent and stable (including their Prefix relationship), so they 
cannot be removed. Note that Encloses describes the function of the 
subtag, not necessarily the linguistic relationship (although in 
practice we hope that both are true).

> Can an extlang be
> dropped from a Encloses field? (if advances in linguistics show that
> it was wrongly added here, for instance.)

I would assume that an extlang can't be dropped from Encloses, since 
stability rules prevent the Prefix or status of an extlang from changing.


  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).

You mean a new extlang? Of course new extlangs could be added as ISO 
639-3 assigns new codes. But there is no such thing as an existing 
extlang acquiring a new Prefix (and thus a new Encloses relationship). 
It is banned by stability rules.

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

The extlang records have a computable relationship. The main problem 
will be grandfathered primary language subtags that are enclosed by 
other subtags linguistically but not in terms of tagging practice. That 
is, not all possible macrolanguage relationships are described by or can 
be computed from entries in the registry.

> 
> 3) 4646bis does not indicate an upper bound for the length of a field

There isn't one.

> ("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.

Note that some comments approach or even exceed the sizes you note above.

I would tend to propose that we make Encloses a single field with 
structure simply because I find the multiple repetition of the same 
field unaesthetic. Of course, we went the other direction with Prefix, 
so there is some precedent for repeating the field.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.


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