Re: A Few Possible Use cases

I think these are reasonable scenarios; however, the description of
the 'solution' must be spelled out. That is, the real requirements are
masked under the heading of 'internationalization context'. These need
to be spelled out in all of the scenarii, so that we see exactly what
is required.

For #1: customer's preferred language, 'courtesy'* currency,
credit-card information, billing address, credit-card address.

*The site may only offer a limited number of these 'courtesy'
currencies, so even though my preferred currency may be Swedish
crowns, I may be limited to rubles, euros and dollars.

For #2: customer's preferred language, and the currency *of the
transaction*, credit-card information, billing address, credit-card
address.

* may not be the customer's preferred currency! My preferred currency
might be dollars, but I might have ordered in Yen (because that is
what the site offered); that will be what is charged to my credit
card.

For #3: customer's preferred language, and the currency *of the
transaction*, credit-card information, billing address, credit-card
address, ticket delivery address, mileage numbers (airline, hotel,
car), reservations numbers, customer's preferred timezone.

Other customers may have other requirements. We are working with one
that requires at least: transaction currency (again, NOT derivable
from the customer's country), customer's country of residence,
customer's bank account country, recipient's country of residence,
recipient's bank account country.

I may be missing a few things here; we need to flesh these out until
they are real-to-life.

Mark Davis
________
mark.davis@jtcsv.com
IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193
(408) 256-3148
fax: (408) 256-0799

----- Original Message ----- 
From: "Debasish Banerjee" <debasish@us.ibm.com>
To: "Addison Phillips [wM]" <aphillips@webmethods.com>
Cc: <public-i18n-ws@w3.org>
Sent: Wednesday, May 21, 2003 15:29
Subject: A Few Possible Use cases


>
>
>
>
>
> Hi,
>
> Here are initial ideas for a few use cases dealing with eBusiness
and
> business choreography.
>
> 1.  Assume the existence of an online store in some country (say
Russia)
> offering various goods and services (Caviar, Vodka, Matruskas, Chess
> lessons, Science books, etc.). The base price of each good is in
Russian
> currency: Rubles. For a non-Russian customer, not familiar with the
Russian
> currency system, the price of the offered goods and services in
Rubles may
> make very little sense. For non-Russian customers, the online
catalogue of
> the retailer may intend to display prices in two currencies: the
base price
> in Rubles, and an approximate price in the default currency derived
from
> the country code portion of the customer's locale. Thus an American
user
> will see prices both in US $ and Russian Rubles; a Japanese customer
in
> Japanese Yen and Russian Rubles and so on. A Russian customer will
of
> course see the prices only in Russian Rubles.
>
> The system can use some local 'currency conversion' module (or even
a
> remote 'currency conversion' web service) for converting Rubles into
other
> forms of currencies. If a default currency can not be derived out of
> 'caller's locale', the default base currency can always be used.
>
> Note that, the values displayed in customers default currencies are
> approximate and intended for user friendliness. During the actual
business
> transaction, when the buyer submits his credit card, the accurate
currency
> conversion will be performed--most probably by some specialized Web
> services interfacing with the financial institutions.
>
> 2.  Again assume the existence of an online retailer selling goods
(say
> books). Assume a Japanese customer ordered a few books from the
catalogue
> after supplying his/her credit card details to the retailer. The
online
> store software after accepting the order will probably send
asynchronous
> message(s) to it warehouses(s) requesting the actual shipment of the
books.
> The warehouse(s) after shipping the order will probably eMail the
customer
> about the shipping details: courier(s) used, the tracking number(s),
> date(s) shipped, expected date(s) of arrival at customer address,
etc. The
> eMail is generated from a standard template and SHOULD be produced
in the
> customer's locale (language). This requires the propagation of the
inbound
> caller's international context information in the asynchronous
messages(s)
> from the eStore to warehouse(s). Since warehouse(s) typically
require a few
> days for actual shipment, the internationalization context should be
stored
> along with the order until the entire transaction gets completed.
The eMail
> to the customer SHOULD also show the amount charged to his credit
card
> formatted according to customer's locale and not in the locale of
the
> warehouse server.
>
> In real life scenario, other intermediate eMails may get directed to
the
> customer during the entire business transaction. One or more books
may be
> temporarily out of stock, partial shipment, etc. All these
communications
> SHOULD originate from appropriate servers of the online retailing
system in
> the locale of the customer.
>
> 3. Imagine a travel agency service providing complete travel
assistance
> including airline reservation, car rental, hotel reservation, etc.
Customer
> submits a travel itinerary and the travel agency fires three
parallel
> processes to process airline, hotel and car rental reservations
based on
> the input itinerary. Imagine, two reservation tasks succeeded (say
airlines
> and car rental) and the third one (the hotel reservation) failed.
The
> travel agency will now compensate the already reserved airlines and
car
> rental bookings. As a part of the overall compensation, the travel
agency
> software informs the customer too. Sophisticated systems may suggest
> alternative itinerary to the customer. The material communicated to
the
> customer may get generated from standard templates and SHOULD be in
the
> customer's locale and not in the locale of the travel agency server.
This
> requires the storage of the inbound customer's internationalization
context
> to be stored until the entire long running transaction (LRT) gets
complete.
> The stored internationalization context may get used in driving
parts of
> the compensation logic.
>
>

Received on Wednesday, 21 May 2003 20:09:50 UTC