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"
