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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

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

Subject: FW: core components analysis

Sue Probert
Director, Document Engineering
Commerce One
Tel: +44 1332 342080

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



Sue Probert
Director, Document Engineering
Commerce One
Tel: +44 1332 342080

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

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