RE: [Distributed services] What is i18n on web services based web applications

Thanks Addison.  I agree with most of your posting.
It is somewhat idealistic, but I think it a goal that we 
should be striving for nonetheless.  My expectation is that
most data will be I18N neutral and the rest we will just have
to accept the way it comes (probably in the locale of the 
service instead of the locale of the client).

Let me give a concrete example that is faced when getting
data from a Oracle database.  Oracle is perfectly willing to
execute a query according to the clients locale.  All you have
to do is set the locale first and then submit your query.  You
can switch locales for every query if you wish.  If you have
a webservice that is brokering requests from clients all over
the world, then you might actually have to reset the locale before
every query.  My assessment is that the Oracle implementation is
still insufficient to realistically expect webservices to take
advantage of it.  I think sending a separate command to set locale
before every query is too much overhead and will not typically be
done.  Perhaps I am wrong, but this is my assessment.  A better
implementation would allow each query to carry the locale with it.
Then you would not double the number of commands sent to the database.

Suppose the SQL language had been designed with I18N in mind, then
perhaps there would be a built in clause that would allow the locale
to be specified with every query.  That would be great.  But locale
is probably just one kind of information that might be useful and
if the SQL inventors had done this, they might have felt obligated
to add clauses for all sorts of environmental parameters that might
affect a query.

Perhaps instead of sending a locale id along with a SOAP request or
some other webservice request, we should send a generic "environment id"
that incorporates many different parameters.  Perhaps a webservice
would first allow the client to specify everything they want to about
their enviroment (including locale) and have the webservice return an
id that the client then includes in all subsequent requests.

Just my two cents.
-Paul

Paul Deuter
Internationalization Manager
Plumtree Software
paul.deuter@plumtree.com 
 


-----Original Message-----
From: Addison Phillips [wM] [mailto:aphillips@webmethods.com]
Sent: Friday, April 05, 2002 11:45 PM
To: www-i18n-workshop@w3.org
Subject: FW: [Distributed services] What is i18n on web services based
web applications


I originally posted this incorrectly on this list.

Thanks,

Addison

-----Original Message-----
From: Addison Phillips [wM] [mailto:aphillips@webmethods.com]
Sent: Monday, April 01, 2002 10:18 AM
To: www-i18n-workshop-request@w3.org; locales@yahoogroups.com
Subject: RE: [Distributed services] What is i18n on web services based
web applications


All:

I've been trying to catch up with the locales group and trying to make
up my
mind about their efforts (what is it? should I support/join in? is it
germane to stuff I'm working on?). In general, I agree with Noji-san's
message and the idea that this represents a different qualitative and
quantitative problem than "locales" is working.

I think I would state the problem differently: distributed systems such
as
Web Services need an I18n architecture. [As opposed to "we need an I18n
architecture which can be used for ......]

As a result, I don't think this actually requires a whole new locale
model.
Architecture, yes, but more along the lines of a protocol than an
infrastructure.

I fear that an infrastructure might not be accepted because it would not
be
simple enough (we would understand it in this forum, but the authors of
SOAP
et al aren't thinking all that much about it, as near as I can tell.
There
is an expectation that xml:lang already does this, I believe.).

Perhaps I am misreading the intentions and direction of the locales
group in
this, but I don't see why I need the full range of locale data or
preferences in an XML document, especially a Web Services document such
as a
SOAP envelope. Correctly structured data is nearly always locale neutral
(the data model in SOAP for example sees to that).

That said, there is a role for locale in XML and distributed systems.
For
example, the sort order of a collated result set (series of records) in
an
XML file should probably match the expected order of the client...

I think what is lacking is:

1. A simple, well-documented standardized way of negotiating (indicating
and
fulfilling) locale preference on the web (can we formally co-opt
Accept-Language, seeing as almost everyone uses it as both "locale" and
"language choice"?) and especially in Web Services (possibly via an
"xml:locale" tag). This is not the same thing as indicating the
locale/format of returned data. These are two separate things.

   1a. SOAP in particular needs to have a locale passing mechanism.
There
needs to be thought given to how multiple hops on the way to the
destination
handle locale, for example. I realize, from several long chats with our
WS
folks, that SOAP has gone out of their way to avoid protocols, but I
firmly
believe that the locale passing belongs in the envelope and I think it
should be defined at the most abstract level so that the most
implementations inherit good i18n behavior. Call me crazy.

2. A simple, well-documented standardized way of indicating language
preference in XML (recall that xml:lang is an attribute, not a
request-->
using an attribute with a specific scope to imply the language desired
seems
haphazard, and what if you don't have an object that takes an xml:lang
attribute in your request?).

3. The rules for handling these requests (chaining, negotiation,
defaulting/fallbacks, what to do if no locale is requested, what to do
if
multiple locales are requested, etc.) would also be a useful adjunct
(perhaps this is part of the locales group's project already??)

The locales group appear to be defining both a complete i18n model
(locale
model) and an XML schema for transmitting the locale identifier or
specific
elements or facets of a locale. This is good work and useful. But I
don't
actually expect to need 99% of that. What I would like is something
simple
that can be promulgated to a large number of other WGs to get the
desired
result: hooks for our systems to use their already formidable
multi-locale
support with external systems.

Thanks,

Addison

Addison P. Phillips
Globalization Architect
webMethods, Inc.
432 Lakeside Drive
Sunnyvale, California, USA
+1 408.962.5487 (phone)
+1 408.210.3569 (mobile)
----------------------------------------
Internationalization is an architecture.
It is not a feature.





-----Original Message-----
From: www-i18n-workshop-request@w3.org
[mailto:www-i18n-workshop-request@w3.org]On Behalf Of Kentaroh Noji
Sent: 2002?3?28? 4:08
To: www-i18n-workshop@w3.org
Subject: Re: [Distributed services] What is i18n on web services based
web
applications



David, thank you for your information.
Because I have ever worked on locale as a member of an open source,  I
agree
that locale is important i18n. However, the net message of my opinion on
this mailing list is a little bit different.

My message is:
W3C i18n can define a model or an architecture of internationalization
for
web based client/server/distributed programming, because W3C works on
not
only XML based document processing but also web based callable
programming
interface such as Web Services. It may be impossible to mention about
i18n
on the specific technologies such as Java2EE, script languages for CGI
etc,
but it is possible to specify an conceptual i18n architecture/model of
web
programming including SOAP.  I think that the appearance of Web services
is
a trigger to work for that.

Thanks,
Kentaro Noji
Globalization Center of Competency, Yamato Software Lab., IBM

Received on Sunday, 7 April 2002 19:37:23 UTC