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