RE: Code Lists & Misspellings : core components analysis

["Blantz, Mary Kay" <mblantz@netfish.com>]

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:ashok.luthra@swift.com]
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"