[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Code Lists & Misspellings : core components analysis
Sue, Your use case was an eye-opener for me. I wonder 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. Cheers, Brian Hayes > -----Original Message----- > From: Probert, Sue > Sent: 19 December 2000 11:29 > To: ebXML Core > Subject: RE: core components analysis > > > Hi William et al > > Sorry to spoil the story but in the majority of cross-border > trade textual > names of coded elements are still absolutely necessary and > they have to be > spelt exactly as on the Letter of Credit or as the buyer, > seller or third > party require on any of the fifty to eighty documents that > still, even in > this internet day and age, have to be printed in order to complete the > transaction. This means that all relevant applications need > to house the > precise spelling and this may not be obtained directly from > an official code > list and therefore the textual name needs to be exchanged in > any electronic > document exchange as well. > > 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. > > regards > > Sue > > Sue Probert > Director, Document Engineering > Commerce One > Tel: +44 1332 342080 > www.commerceone.com > > > -----Original Message----- > From: William J. Kammerer [mailto:wkammerer@foresightcorp.com] > Sent: 18 December 2000 20:52 > To: ebXML Core > Subject: Re: core components analysis > > > Duane Nickull showed us a snippet of XML which might throw an > application off course which was looking for Belgium as the country of > origin: expecting the French name "Belgique" as a trigger in the > <importeDe> element, it would have overlooked "Belgium." Duane thinks > "that there is only so much we can do." > > Dear Duane: > > 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. > > 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" >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC