[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Code Lists & Misspellings : core components analysis
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"
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC