Re: Code Lists & Misspellings : core components analysis

["William J. Kammerer" <wkammerer@foresightcorp.com>]

Like Brian Hayes, I too thought Sue Probert's use case was an
eye-opener. Sue gave the hypothetical example of an export consignment
of beer leaving Rotterdam, but they had the Port of Loading misspelled
as "Roterddam" on the original Letter of Credit.   If only the UN/LOCODE
for Rotterdam, NLRTM, were sent, the bad spelling would not be
reproducible. This would presumably lead to all sorts of bureaucratic
havoc, with the beer stranded on the dock and thirsts left unquenched in
some remote reach of the world.

Brian now "[wonders] if there is a place in one of the ebXML models to
capture the code list to spelling mapping for any given business process
instance or business collaboration instance.  In this example, I believe
cross-border trade to be a business collaboration."

Dear Brian:

I haven't seen such a model, though why would such a trivial activity -
mapping a country code to the official English or French text - have to
be modeled?  Gawd!!! - Do we really need any more UML diagrams? Perhaps
it could be a function of the Repository, which might hold the ISO 3166
list and associated methods to search and manipulate it.   Even then, I
can imagine the mapping to be something needed only at the application
level - let the recipient worry about the mapping.  I didn't think we
were modeling applications, just inter-enterprise collaborations.  But
then, I can't read these things - UML models -  so I don't know what BP
is doing with them.  The converse, mapping from the natural language to
the country code would be extremely difficult and fraught with error;  I
don't know if that's what Duane Nickull had in mind, though:

   Keep in mind that a handler written as a post parse process
   will barf if one letter is different or even case different.
   An application will not look at "belgium" and know it is the
   same as "Belgium" or "belgique" unless we tell it to.  Add
   the business rules that Sue described into the equation and
   there is a huge [potential] for confusion.

Huge potential for confusion, indeed!  "E.E.U.U.,"  "United States,"
"United States of America," "United States of Mexico,"  "Canada," and
"Kanada." Some things are better left unautomated.

Sue's example concerned misspellings having to be preserved along the
way, even if mechanically processable country codes were available.  But
her example is not just limited to misspellings: I write "Antwerp," but
I thought they wrote "Antwerpen." I write "Brussels," they write
"Brussel" or "Bruxelles." Sue knows the business - do people really get
bent out of shape over this? The whole point of the UN/LOCODE was to
avoid just those mix-ups by having all location information transmitted
by a single code.

Shades of EDI!  Now we'll have to send not only the UN/LOCODE, but also
the port spelled out in any number of variants.  The UN/EDIFACT LOC
segment all over again.  So what is it here we're trying to fix? If
everyone has to be kept happy along the way by propagating the
misspelling, then not only is this problem not "far fetched," it just
points out that serious reengineering is needed in applications to make
effective use of B2B interoperability.

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"