Mike:
The problem we ran into with xCBL (which had a stated goal of wanting to
support EDI use of codes) was "which set of codes?"
To simplify:
There are three types of codes:
(1) ISO code lists supported by everybody: ISO currency, language, locale
(often through the UN/ECE) - we used these as is. As you say, it's a "no
brainer." Complete agreement from me.
(2) X12 codes
(3) UN codes (from the codes working group)
There is a huge degree of overlap between 2 and 3, and sometimes the *same*
alphanumeric code represents different semantics in 2 and 3. This is very
confusing. Both are heavily used in business applications. SMEs cannot
afford the kind of tools that make this problem easily tractable.
What we did, to try to meet expectations of x12 users and UN/EDIFACT users,
was to compare the codelists from 2 and 3, identify the overlap, and then
come up with an "intuitive" single-word "code" that was mapped back to it's
sources (usually X12 and UN codes). Thus, we didn't have to answer "which
set of codes?" - we supported both without using either.
This is the kind of approach that I think UBL should also take, since it
provides support without inheriting the problems associated with making a
choice betwen 2 and 3.
Also, we will want to discuss how far we should go towards accomodating the
capabilities of legacy systems, since I don't think that this is a
show-stopping issue for people adopting a new vocabulary. Basically, what we
are telling them is that they have a new set of mapping tables, and the new
codelists use 9 characters instead of 3. (Or whatever constraints we choose
to put on the UBL codelists members).
While I agree with your basic practical approach to this, there are some
problems here that we will need to solve.
Cheers,
Arofan Gregory