- From: Debasish Banerjee <debasish@us.ibm.com>
- Date: Tue, 14 Jan 2003 18:23:27 -0600
- To: "Addison Phillips [wM]" <aphillips@webmethods.com>
- Cc: <public-i18n-ws@w3.org>
Addison,
Thanks for drafting out a very nice initial requirement document.
I have certain general comments and questions related to your document.
Some of the comments in terse forms may be considered as candidates for
inclusion in your list of requirements.
1. Do we have to treat 'language' and 'locale' separately? As you very
mentioned, this can generate unnecessary confusion. Can we consider
'language' to be an optional part of a 'locale'?
2. Instead of terms like "Accept-Language', 'Accept-Locale',
'Content-Locale', I prefer the use of the term 'Internationalization
Context'. A 'context' is (a) system level information, and (b)
transparently provided and managed by middleware infrastructure. A
system-level data should not appear in any application-level method or
operation signatures. To maintain remote-local transparency in distributed
heterogeneous managed environments we need to use contextual system-level
information containing locale(s), etc. I view this particular category of
contextual information as the 'Internationalization Context'.
Note that in your example of "addInts(...)" we are actually using
'internationalization context', which is transparently propagated, managed,
and made available (using APIs) by the so called "Web service
container'--the middleware.
I believe, there is no need to deviate from the principle of 'not exposing
any contextual information in method signatures' in your "compareStrings()"
example. That 'userLocale' parameter in this particular example should also
be viewed as an implicit parameter derived from the 'invocation
internationalization context'.
Incidentally, your "compareStrings()" example highlights the 'life-cycle
management' policy for internationalization context. The
internationalization context probably has the shortest life-cycle span when
compared to other contexts. Within a user 'session', the
internationalization context can potentially be different during each
interaction with the Web service.
3. Whether contexts will be carried in headers (for SOAP) or trailers (for
XYZ protocol) is an issue related to binding. First we need a formalism to
express contextual information in WSDL fundamental entities like
'serviceType', 'portType' etc. WSDL binding specifications can then define
the exact mechanisms for propagating various contextual information
including our internationalization context. For SOAP-binding of WSDL,
certainly all the contextual information should be carried in SOAP headers.
4. We may need to express the management policies and attributes related
to 'invocation internationalization context' (and in general for other
types of contexts too) at various levels of granularity in WSDL
descriptions. The default management policy for internationalization
context must be 'runAsCaller'.
All the management policies are to be enforced by Web service containers.
For container-managed instances, a Web service programmer should not able
to change the internationalization context programmatically. In isolated
instances though, a Web service developer may want to exercise complete
programmatic control over the invocation internationalization context for
one or more components. The WSDL of those components can be associated with
something like "Application Managed Internationalization" policy.
The management policy (container-managed internationalization or
application-managed internationalization) and attributes (runAsCaller,
runAsServer, runAsSpecified) can be specified at various levels at WSDL
components. WSDL need to define how the policy specified at a higher level
entity (say associated with a portType pT) affects the policy at a related
lower level entity (say operation oP contained within pT).
The management policy and attributes should be made available at Web
service discovery namespaces like UDDI. An Web service client should be
able to browse UDDI namespace and base its selection of a Web Service using
its internationalization context (probably along with other contexts too)
management policy and attributes. Certainly for a general Web service
client, the 'runAsCaller' deployment attribute of a web service W1 promises
more towards distributed localization when compared with 'runAsServer'
attribute for a similar Web service W2. If all other factors are the same,
the Web service requester may select W1 for its superior
internationalization capability.
5. Do you think that 'time zone' should also be a part of
internationalization context? This is a very sensitive question. I know for
sure that some distributed architectures are already frustrated with the
Daylight Savings business and are embracing UTC. Still for user's
convenience, shall we propose to carry the time zone information along with
locale(s) in internationalization context? UTC-oriented Web service
components may simply ignore the time zone present in internationalization
context.
6. To my knowledge there is no standard definition of locale. The
RFC3066-type tags is probably suitable for modern programming environments
like Java, C#, ICU, or the ANSI C++ library (I am not too sure about it, I
have to double check). POSIX, and XPG4 (the classical C and C++
internationalization environment) can not natively provide a multi-locale
enabled (ML) environment anyway. I do not know about native Macintosh
environment. Can a native Macintosh programming environment be ML enabled?
For systems which do not recognize RFC3066-type tags, can we go for
pluggable adapters? For interoperability, the adapters will be used by Web
service containers for converting (often approximately) RFC3066 type of
locale data to the native locale and back.
I guess we can discuss these and other issues in our next teleconference.
Thanks,
Deb
"Addison Phillips
[wM]" To: <public-i18n-ws@w3.org>
<aphillips@webmeth cc: Debasish Banerjee/Rochester/IBM@IBMUS
ods.com> Subject: [WSTF] My view... [long]
Sent by:
public-i18n-ws-req
uest@w3.org
01/13/2003 06:09
PM
Folks:
This email outlines my approach to the locale/language issue we discussed
in the last telecon. It is somewhat long.
I consider "locale" to be an environment setting or settings that govern
how data is (to be) processed. Language preference may either be an aspect
of "locale" or may be a separate environment setting. There are cases
(described below) in which the locale is also a data element which is part
of the processing, but this is a special case and I think it is important
to deal with it as such.
In traditional software, the developer doesn't need to explicitly obtain a
Locale object or setting in order to write internationalized code. The
default behavior of locale-aware functions obtain and use the locale from
the system environment. Yes, the developer must call the correct functions
or methods, but s/he must only obtain a locale when the desire is to
override the user's preference (the default).
A notable failing of enterprise and client-server architectures has been
the failure to simulate this relationship and provide multi-locale support,
that is, a server that can process data for clients running in different
locales at the same time. Well-designed "ML" client-server systems
negotiate the locale for each client session with the server and the server
tracks and processes data with the client's preferences.
Web services are a form of client-server architecture in which the "Web
service container" calls a function or method for the "client". There is a
"service description" (WSDL file) that describes to the client what data to
pass, where the container server is, what protocol(s) to use, and so forth.
The client uses the service description to build a SOAP document containing
the necessary fields (required and optional) and sends it to the container,
which invokes the actual service with the data.
If there is a failure, a SOAP fault is sent to the client. The failure can
be in either the container or in the service itself. Depending on the
nature of the service, the container may or may not return a SOAP document
with data or a result.
Now the problems here are:
1. When designing the actual service (the underlying method or function),
the developer should not need to deviate from standard i18n practices. If
the service's data model doesn't require a locale, then the developer
shouldn't have to artificially provide one just to internationalize the
service. Consider a Java method that adds to integers together:
public int addInts(int var1, int var2)
The method is not locale affected, nor does it take or return any locale
affected data types or values. However, the method may return an error
message ("loss of precision" or "integer overflow", for example), so it
needs to provide for localization. It is unnatural to force the developer
to specify the method as:
public int addInts(int var1, int var2, Locale userLocale)
The Web service container should provide this functionality.
2. When generating WSDL for a service (as part of deploying the service), a
multi-locale enabled container may add its own proprietary header value
that allows the client to specify the execution locale. Since the extension
is proprietary, it may not be possible for the client to accurately provide
a suitable value to the container. Likewise, the client may not be able to
interpret the results. Consider some WSDL generated by the product I was
using at the FTF. As a Java product, it rendered java.util.Locale objects
by using the constructor that takes three strings: "language", "region",
"variant". How would a C#, C++, or perl program invoke this service
accurately?
In other words, a proprietary solution may not be interoperable and may
expose the implementation to readily.
3. If the service container generates its own header, this may conflict
with a service that reasonably does require a Locale argument to invoke it.
Consider this Java service:
public int compareString(String var1, String var2, Locale userLocale)
The userLocale allows the client to override the default locale to get the
result. If the container also generates a proprietary header, the client
may have a hard time implementing the service correctly. And the semantics
may vary for "locale".
4. If the service is not internationalized or has limitations on its
invocation (consider many legacy host systems), there is no way to tell how
the service was actually executed or to know about these limitations.
---
Aside: These last two scenarios Deb described in an off-list email last
week. These are "runAsClient", "runAsSpecified" and "runAsServer"
scenarios, Deb.
---
IMHO, the "big picture" (requirements) here are:
1. Web services needs a non-proprietary negotiation mechanism for locale
and language preference.
2. The mechanism should be based on locale tags or an XML "locale" or "i18n
context" data structure that is platform neutral.
3. The mechanism should be part of the service invocation context (e.g. in
the header or envelope, not the payload or body). Implementers should
create APIs and runtimes that use this as intended (described above), but
non-i18n implementations will merely ignore it or get locale-of-the-server.
4. Services that need a locale "object" may use the tags/structure in the
body (e.g. in the service's "contract") to pass locale information.
Developers can thus provide "i18n demo" services ;-).
5. The mechanism must be able to deal with both client preference
("Accept-Locale") and server capability ("Content-Locale"). It must have an
analog for the "null" (neutral, POSIX, C) locale.
6. Web services providers and client vendors should be able to count on
this mechanism being available and invoke services with it without knowing
if the back-end system can service their requests. This is a way of saying
this is not "mustUnderstand", I guess.
I'm on record as favoring tags over an XML structure, but I'm willing to be
persuaded (and try persuasion ;-)). I have use cases galore from webMethods
that relate to the various aspects of the above.
Some things to think about:
--RFC3066 language tags (that is xx-YY) are sufficient for identifying Java
locales and possibly C# CultureInfos, but not for POSIX, C/C++, Mac, and
other native programming environments.
--There is bound to be confusion about language ("Accept-Language") and
locale.
I have lots more to say, but let's start with this. Is this an accurate
description of what our requirements should be? How can I flesh out the
problems better?
Best Regards,
Addison
Addison P. Phillips
Director, Globalization Architecture
webMethods, Inc.
+1 408.962.5487 (phone) +1 408.210.3569 (mobile)
-------------------------------------------------
Internationalization is an architecture.
It is not a feature.
Chair, W3C-I18N-WG Web Services Task Force
To participate see http://www.w3.org/International/ws
Received on Tuesday, 14 January 2003 19:26:18 UTC