OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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.

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

> I don't see the difference between tag names and codelists in terms of
> naming, or why our approach to the two should be different. Since we all
> seem to agree (rightly in my opinion) that tag names should be clear and
> human-readable, why wouldn't this apply to codelists?

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

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

  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... )
Fabrice Desre - France Telecom R&D/DTL/TAL
Tel: +(33) 2 96 05 31 43
Fax: +(33) 2 96 05 39 45

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC