Mike Rawlins wrote:
>
> Phil Griffin wrote <snipped>:
>
> > > I don't see the problem. Is there something here I'm missing???
> >
> > No problem. Just use 642 and you've got a stable
> > identifier that's independent of national language. :-)
> >
>
> I don't think this is a solution. If we did a quick check, I'll bet that most
> business applications actually use the 3 character ISO code. That means that they
Perhaps. Maybe not.
> already have the "ROU" vs. "ROM" problem that you're referring to, and there's nothing
> we can do to fix that for them. If we tell them to use the numeric code, we're
I disagree. Above is the suggested fix. I very
much disagree with staying with a broken status
quo just because the user is already accustomed
with suffering. I thought we were building a new
and better world here, not just patching the old
one.
> forcing everyone to convert to and from the numeric code when they could just use the
> alphanumeric code.
Again, I don't believe that is the case. All I'm
saying is validate against the number, and display
the associated alphanumeric for the user. As in
perhaps
<country name="ROU"> 647 </country>
or
<country name="ROM"> 647 </country>
or
<country name="ROU" fullName="Romania"> 647 </country>
But, look, I totally agree that if this presents an
unreasonable burden on the community, a cost issue,
then I'm all for what is most practical.
But when you look at the cost issue, consider the
cost of maintaining a "ROU" list that breaks right
before our eyes. That is, the list in an example
posted a week ago, if it listed "ROM" and not
"ROU" is already bust before we even publish.
> I think that for the rare cases where there are both alphanumeric and numeric versions
> of the same code list, we should let the business folks (the library SC) decide which
> to use.
> --
> Michael C. Rawlins, Rawlins EC Consulting
> www.rawlinsecconsulting.com
Phil
