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

[Phil Griffin <phil.griffin@ASN-1.com>]

Matthew Gertner wrote:
> 
> > > 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.

Matthew. Even people who are kind enough to speak
English when I visit their countries are not likely
to want to use English to conduct their business
or personal affairs.

Really, there's more in the world than McDonalds 
hamburgers. And my bet is that some dialect of
Chinese is probably the big winner in the most
spoken category.
 
> > > 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?

It refers to "National Language" support or service.
Many countries have their own languages. Quite a lot
of them are not English. :-) If you and I are lucky,
the use of English will continue to grow. There's a
joke that bilingual means that you speak more than
one language and American means that you speak only
one language, not well.
 
> > > 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)?

I'm guessing that some folks see two and three 
character codes as display items, since their
use would facilitate efficient data entry, and
being fixed length would lend themselves to
fitting easily on forms.

But I think the central point that Fabrice (and later
Mark) has made is that these codes are DATA not labels
for data.
 
> >   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.

Not for me. Cost is nearly everything. I'm really
leaning in the direction now of Mark and Fabrice's
lead - we would be smart to push the maintenance
and legal responsibilities off on the UN and others
and look where needed to the application to do the
validation.

The application can compete at the user interface level
in ways that do not impede data exchange interoperability,
say by perhaps displaying Romania in several languages if
it so chooses. We don't have to dictate that, just get
them the data reliably.

The point is, this gets us off the hook and allows us
to move on quickly to more important topics, of which
there are quite a few.

> Matt
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>