[WSTF] My view... [long]

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 Monday, 13 January 2003 19:09:42 UTC