OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Code Lists & Misspellings : core components analysis


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.

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
> 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]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC