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

RE: A Few Possible Use cases

From: Addison Phillips [wM] <aphillips@webmethods.com>
Date: Tue, 10 Jun 2003 07:57:06 -0700
To: "Debasish Banerjee" <debasish@us.ibm.com>
Cc: <public-i18n-ws@w3.org>
Message-ID: <PNEHIBAMBMLHDMJDDFLHMEOBGLAA.aphillips@webmethods.com>

Hi Deb,

Thanks for sending this. Hmmm, I think these use cases don't really
demonstrate what you're trying to show.

It isn't a lack of realism that makes me unsure of these cases. It's just
that, given the mechanisms in SOAP/WSDL/etc., one can design these
applications without resorting to a contextual mechanism. In fact, if I were
to design any of these scenarios, I wouldn't want a context: I'd include the
necessary "context" in the user profile, a necessary precursor to any of
these applications, or in the data structures exchanged in the service

For example, the first scenario offers optional currency values. It would
make the most sense to define two optional inbound messages, one that takes
no currency (for folks who want to see only RUR) and another that takes a
list of currencies (for folks who want to see the approximate values in EUR,
CZK, USD, and so forth).

A more general approach would be that descriptive fields may be culturally
linked. For example, a product that is "seafoam green" is likely to have a
very different name in, say, German. This is the sort of catalog information
which is localizable and thus may be influenced by a language preference. In
fact, in designing a catalog application I'd consider how the location of a
customer would impact the information in other ways (like discount,
shipping, taxation, packaging, product desc., regulatory reqs., etc.).

If the user must be "random" (unknown in advance) it is still necessary to
gather as much of the "contextual" information >>explicitly<< as is required
to serve the application's needs. This may include country, language, etc.

I would look for cases where such a user profile is unnecessary to
performing the transaction (for example). Or for cases where the natural
execution of a service (or a simple process) wouldn't require the
international context explicitly in the service signature, only implicitly.
I think the cases in your email involve specific design time decisions, but
don't require a separate "context" (locale).

That's my first-blush thought. Let's talk about it next week at our next

Received on Tuesday, 10 June 2003 10:57:24 UTC

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