Re: A Few Possible Use cases

It appears that my reply to your earlier message was not received. Can
you verify that you got it this time?

Mark
__________________________________
http://www.macchiato.com
►  “Eppur si muove” ◄

----- Original Message ----- 
From: "Mark Davis" <mark.davis@jtcsv.com>
To: "Addison Phillips [wM]" <aphillips@webmethods.com>; "Debasish
Banerjee" <debasish@us.ibm.com>
Cc: <public-i18n-ws@w3.org>
Sent: Wednesday, May 21, 2003 17:09
Subject: 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.
> >
> >
>

Mark
__________________________________
http://www.macchiato.com
►  “Eppur si muove” ◄

----- Original Message ----- 
From: "Debasish Banerjee" <debasish@us.ibm.com>
To: "Addison Phillips [wM]" <aphillips@webmethods.com>
Cc: <public-i18n-ws@w3.org>
Sent: Monday, June 09, 2003 17:28
Subject: A Few Possible Use cases


>
>
>
>
>
> Hi,
>
> (a) I am reposting essentially the same note that was posted
earlier. I
> just
> added a paragraph about Metric <--> English (?) conversion in use
case (1),
> as
> suggested by my colleague from Shanghai.
>
> I would like to have discussions about the 'application-level' (ref.
> Addison) use
> cases during our "Tuesday Afternoon Teleconference" (just trying to
mimic
> late Prof.
> Dijkstra's famous "Tuesday Afternoon Club"). We can discuss the
comments of
> Dr. Davis and Addison, make the use cases closer to real life.
>
> (b) Here is one URL for the WS-Policy document:
> ftp://www6.software.ibm.com/software/developer/library/ws-policy.pdf
>
>
> Thanks,
>
> Deb
>
>
>
> ======= O L D   N O T E ======================
>
> 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.
>
> Just like the case of user-friendly currency, the proposed online
store
> can also help a potential customer by performing "metric -->
English"
> conversions
> when appropriate. A traditional American customer may want to see
the
> weight of
> Caviar in ounces (not in grammes) or the volume of liquids in pints
> (not in liters). Based on the inbound locale, the online catalogue
may
> display the weight, volume, etc. in two systems: the base system
(almost
> sure
> that Russia follows the metric system) and the system usually
associated
> with locale (say the English system for the American customer).
>
> 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 Monday, 9 June 2003 22:28:27 UTC