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 >