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

["CRAWFORD, Mark" <MCRAWFORD@lmi.org>]

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

IMHO we are loosing sight of a very distinct difference between human readability/semantic clarity of tags and human readability/semantic clarity of data (codes).   It's not our data that we want human readable! There is no way that we can ensure or control semantic clarity of data, nor should we entertain any thoughts of trying to do so. 

A tremendous amount of work has gone into establishing code lists to provide tokens for data values that are clear, unambiguous, and easily mapped to any language specific value of the code.  Avoiding using those code lists for data values and trying to establish English language equivalents just makes no sense, is counterproductive, and does not justify the small processing time savings for transformations from code to language equivalents. 

Mark

> -----Original Message-----
> From: Fabrice DESRE [mailto:fabrice.desre@francetelecom.com]
> Sent: Wednesday, February 13, 2002 7:08 AM
> To: NDR SC
> Subject: Re: [ubl-ndrsc] [Fwd: Fwd: ISO 3166-1 -- Change of
> Alpha-3 Code
> Element 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
> --
> Fabrice Desre - France Telecom R&D/DTL/TAL
> Tel: +(33) 2 96 05 31 43
> Fax: +(33) 2 96 05 39 45
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>