RE: [ubl-ndrsc] [Fwd: Fwd: ISO 3166-1 -- Change of Alpha-3 CodeElement for Romania]

[Matthew Gertner <matthew.gertner@schemantix.com>]

> > Using some kind of language neutral codes, numeric or otherwise, might
> be
> > theoretically (and politically) correct, but it strikes me as a disaster
> > from the standpoint of usability. It is reasonable to expect that the
> vast
> > majority of users of UBL in the foreseeable future will understand
> English
> > better than arcane abbreviations and the like.
> 
>   That's pure speculation IMHO.

Speculation, no doubt, but not entirely pure. First of all, I am drawing a
comparison between English and arcane codes, so it seems likely that the
former is always going to be at least as understandable (i.e. not very), and
to anyone who speaks English (around 1.5 billion people and growing) it is
certain to be far more understandable. Also, the kind of people who will be
using UBL at a document or schema level (as opposed to through a user
interface only) are very, very likely to speak English. I don't have any
evidence for this, but it I am wrong then I officially move for us to begin
holding UBL meetings in Esperanto, since the same issues would presumably be
at stake.

> > Didn't some French guy say
> > "the best is the enemy of the good"? If even the French agree with
> taking
> > the practical approach, who are we to disagree? ;-)
> 
> Yes, but we're not at a point to choose a "better" or a "good"
> solution... we're just looking for a good one.

Exactly my point.

>   Because a code is a value, not the name of a container. And because
> you'll face NLS issues if you apply simple naming rules to code values
> (the use of oxford english for instance).

What is NLS?

> > In other words, the label for Romania should be "Romania". It's just as
> > easy
> > to map this into "Roumanie" as it is for ROU or 642.
> 
>   But how easy is it to maintain ? Since it seems acknowledged that a
> code value has no display purpose, we should use the code list that
> is the more stable. In the particular example of countries, the
> numerical value is the good choice.

This is a good point. I'm not sure how much of an issue this is for the kind
of codelist we will be using. Are the English language labels likely to
change often (e.g. Ceylon -> Sri Lanka)?

>   Moreover, i doubt very much that UBL can afford to maintain many
> codelists that are already maintained by other international
> organisations. Perhaps these codelists should be only referenced by UBL
> schemas, and not be part of them. This delegates the validation phase to
> the application, but this is very likely to be done in the app anyway,
> unless heavy subsetting is achieved by a context rule (and how do you
> maintain your subsetting context rules when the core schema changes ?
> I'm having a bad dream... )

These are totally separate issues IMO.

Matt