Phil:
Something to be aware of generally in this discussion is the way in which
all of our "tag names" are essentially in the same bag as codes: we are
choosing semantic, English-language names for semantic constructs. the
primary need is that they be machine-procesable. Human-readability is a very
useful thing, but not a necessary thing in a business document.
Each tag name points to a semantic construct (BIE and/or dictionary entry)
that has an associated UID. My impression - given that we are based on Core
Components work - is that we would use this UID as the unifying construct
for doing cross-language versions of our library. This is the approach that
Core Components is taking, and I think it is a good one.
In this case, building a separate mechanism for handling language
correspondence would be less helpful, not more helpful. Enumerated values
(codes) would become just another type of "tag name" in the UBL library.
As for what the "codes" look like, referring back to your "840" vs. "USA"
example, it is a big convenience if your primary audience can understand the
string and directly display it to the user interface. I could do this with
"USA" (although it would have to be case-sensisitve if we are relying on XML
tools in most cases) but I probably could not do it as successfully with 840
(I would argue that most business people would understand "USA" better than
"840", your wif's situation being a minority case).
Nothing stops "USA" being presented as "840", as you know. The requirement
to always provide a presentation value, however, places requirements on
application design, and this can have an impact by complicating the
application. My company faced exactly this situation, where one application
group built a product that used the "codes" in xCBL directly, while the
other always did a mapping from a coded value to a presentation form. They
built very different systems based on their assumptions about how codes
could be handled. The team that used the codes directly built a simpler
application, becaue it didn't need to have a lot of code in it for
presentation: it left this up to the customers as a customization using
XSLT.
I am certainly not disagreeing with your basic point, but I am trying to say
that if we already have a system for deriving language-versions of our
library, and we can provide a human-readable form of our "codes", to buy
some degree of simplicity in application design, then that is the right way
to go.
I vote for "USA", and let non-English speakers use tools to get the
presentation they need. UBL has chosen Oxford English for a reason, and I
believe we should follow that thinking in anticipating our audience.
Cheers,
arofan