Subject: Re: FW: core components analysis
"Probert, Sue" wrote: > For example suppose the Port of Loading for an export consignment of beer is > Rotterdam and in error this was spelt as Roterddam on the original Letter of > Credit then by sending only the official UNLOCODE for that location, NLRTM, > the receiving application would not be able to reproduce the original > mispelt name on any paperwork. e.g. original Bill of Lading, which they had > to raise to expedite the cargo movement. > > Far fetched you may think but absolutely not! This is the reality of the > types of challenges that remain for trade facilitation and electronic > trading. Technical solutions, however clever, cannot alone overcome these > problems. >>>>>>>>> > William J. Kammerer Wrote: > > Please don't despair. Because in ebXML we would never identify the > country of origin as either "Belgium" or "Belgique." Rather, we would > insist on codification of countries using the ISO 3166-1 Alpha-2 code; > in this case, "BE" for Belgium - see > http://www.din.de/gremien/nas/nabd/iso3166ma/. Globalization depends on > us using every International standard we can get our hands on - which is > why I sound like a broken record talking about ISO standards and UN/ECE > recommendations. > >>>>>>>>>>>>>>>>>>>>>>>.. I was using this as an example to illustrate the problem which Sue has described more accurately. I realize in the instance of country code this would be true but there are still many more discrepencies, my own bad spelling being a prime example. One thing many of us do is look at these problems from a human readable POV. 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 potantial for confusion. Duane Nickull Duane Nickull > Unfortunately, I neglected to note in my previous message one of the > most prominent West Teutonic languages - Netherlandic or Dutch (ISO > 639-2/T nld) - an egregious omission considering it is English' closest > relative besides Frisian. It's interesting to note - politically if not > etymologically - that Flemish (Belgium Dutch) doesn't rate its own entry > in the ISO 639-2 code list. This reminds me of when I was at the ebXML > meeting in Belgium last May: after the meeting was over, a number of us > embarked on an excursion to Bruge for lace and chocolate. We obtained > our train tickets and boarded a delightful ride. A while into the trip, > the banner sign overhead gave us instructions and stops; reading Flemish > as well as I could, it sounded a lot like "You be comin' on Brugge," > which I guess was as good a translation as possible considering we > eventually came to Bruge. > > Concerning whether the Salish, Mi'kmaq, Innuit and Haida languages are > included in ISO 639-2, you could look it up yourself at > http://lcweb.loc.gov/standards/iso639-2/englangn.html. Indeed, Salishan > is ISO 639-2/T code sal, and Haida is hai. The Mi'kmaq speak Micmac > (ISO 639-2/T mic). But the Innuit speak either Aleut (ISO 639-2/T ale) > or Inuktitut (ISO 639-2/T iku). I think ISO 639-2 can probably handle > anything that you can throw at it, Duane! > > 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