Subject: RE: Code Lists & Misspellings : core components analysis
Dear Ashok, While I appreciate the humour in your message, I must caution you that having that much beer delivered to your home might make your neighbors think that you have a drinking problem. And you would probably get a lot of visitors; probably some unpleasant people who DO have drinking problems. To save you any embarrassment and bad visitors, I hereby volunteer to accept all that beer for you. I live in a large building, so people would not be able to tell that the beer was being delivered to me! Happy Holidays! Mary Kay -----Original Message----- From: LUTHRA ashok [mailto:firstname.lastname@example.org] Sent: Friday, December 22, 2000 12:59 AM To: William J. Kammerer Cc: 'ebXML Core'; ebXML-BP (E-mail) Subject: Re: Code Lists & Misspellings : core components analysis Hello all I also thing that the use case was also very "cool" but to make it even more "cool" , an extend use case should be added so that all misspelled beer consignment should be forwarded to home address . Have a happy Xmas and a happy new year Regards Ashok "William J. Kammerer" wrote: > 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"
Powered by eList eXpress LLC