W3C home > Mailing lists > Public > public-i18n-ws@w3.org > May 2003

Re: A Few Possible Use cases

From: Mark Davis <mark.davis@jtcsv.com>
Date: Wed, 21 May 2003 17:09:08 -0700
Message-ID: <008001c31ff6$5da49970$77d52b09@DAVIS1>
To: "Addison Phillips [wM]" <aphillips@webmethods.com>, "Debasish Banerjee" <debasish@us.ibm.com>
Cc: <public-i18n-ws@w3.org>

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

* 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

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
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
> business choreography.
> 1.  Assume the existence of an online store in some country (say
> offering various goods and services (Caviar, Vodka, Matruskas, Chess
> lessons, Science books, etc.). The base price of each good is in
> currency: Rubles. For a non-Russian customer, not familiar with the
> 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
> the country code portion of the customer's locale. Thus an American
> will see prices both in US $ and Russian Rubles; a Japanese customer
> Japanese Yen and Russian Rubles and so on. A Russian customer will
> course see the prices only in Russian Rubles.
> The system can use some local 'currency conversion' module (or even
> remote 'currency conversion' web service) for converting Rubles into
> 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
> transaction, when the buyer submits his credit card, the accurate
> 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
> books). Assume a Japanese customer ordered a few books from the
> after supplying his/her credit card details to the retailer. The
> store software after accepting the order will probably send
> message(s) to it warehouses(s) requesting the actual shipment of the
> The warehouse(s) after shipping the order will probably eMail the
> 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
> caller's international context information in the asynchronous
> from the eStore to warehouse(s). Since warehouse(s) typically
require a few
> days for actual shipment, the internationalization context should be
> along with the order until the entire transaction gets completed.
The eMail
> to the customer SHOULD also show the amount charged to his credit
> formatted according to customer's locale and not in the locale of
> warehouse server.
> In real life scenario, other intermediate eMails may get directed to
> customer during the entire business transaction. One or more books
may be
> temporarily out of stock, partial shipment, etc. All these
> 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
> including airline reservation, car rental, hotel reservation, etc.
> submits a travel itinerary and the travel agency fires three
> processes to process airline, hotel and car rental reservations
based on
> the input itinerary. Imagine, two reservation tasks succeeded (say
> and car rental) and the third one (the hotel reservation) failed.
> travel agency will now compensate the already reserved airlines and
> rental bookings. As a part of the overall compensation, the travel
> software informs the customer too. Sophisticated systems may suggest
> alternative itinerary to the customer. The material communicated to
> customer may get generated from standard templates and SHOULD be in
> customer's locale and not in the locale of the travel agency server.
> requires the storage of the inbound customer's internationalization
> to be stored until the entire long running transaction (LRT) gets
> The stored internationalization context may get used in driving
parts of
> the compensation logic.
Received on Wednesday, 21 May 2003 20:09:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:38 UTC