Lookup Tables

[Jon Hanna]

[snip]
> > Adding yet another Lookuptable is not a good idea.
> >
> > The problem with LUTs is that they need to be maintained. In the
> > standard, in all the software that has them inside, on all of the
> > installed sofware... a logic in the separator character saves all this
> > maintenance.
> 
> You're going to need lookup tables anyway.  ISO 639-1 and 639-2 language
> codes, IANA-registered language codes, and ISO 3166-1 country codes all
> have to be stored in some kind of table, at least so applications can
> tell when an invalid one is being used.
[snip]

The degree of detail needed would vary considerably with application. Some would need to know no more than a list of the codes which reflect available resources and do little more than atomic comparison, possibly with parsing of the codes as hierarchical being a fall-back option.

Some would need to compare the codes with a proprietary system (e.g. C++ STL locale objects, Microsoft LCIDs etc.) for which a relatively simple LUT would be required.

Some would want to include much richer detail, such as hierarchical information beyond, or even in contradiction to, that implied by the 3066 syntax, geographical information, etc.

Standardised LUTs can't perform those tasks, though they could perform some of them. The very fact that no LUT could perform all these roles, and the fact that they would have to rule quite decisively on controversial issues to be constructed seems to argue against any LUT-based solution to this.