A sender and a receiver wish to use Unicode encoding to transmit data between each other. This scenario provides an example of best practice.

SOAP is used for XML messages exchanging data among service nodes. Because all XML processors must be able to read entities in both the UTF-8 and UTF-16 encodings, using UTF-8 or UTF-16 guarantees character encoding interoperability on the SOAP layer. The Character Model for the World Wide Web document describes these considerations and guidelines.

Note: WS-I: Web Services Interoperability basic profile document describes a problem about Unicode encoding and Byte Order Mark (BOM) handling.

Applies to: SOAP, SOAP interface of software systems

A sender and receiver wishes to use non-Unicode encoding. This scenario provides an example of best practice.

This scenario is divided into three aspects.

When a sender sends a SOAP messages in a non-Unicode encoding to a receiver, the receiver may not accept the non-Unicode encoding. The sender does not always accept all character encodings that may be used with XML. In order to use a non-Unicode encoding in a SOAP message, the sender needs to know beforehand whether the receiver is able to accept the non-Unicode encoding.

Receiver passed SOAP messages to programming languages, middleware, or operating systems via SOAP interface. Through the interaction of SOAP interface, code conversion from non-Unicode encoding to Unicode may happen.

XML Japanese profile document describes that using non-Unicode encodings such as Shift_JIS cannot provide interoperability in information interchange.

Applies to: SOAP, SOAP interface of software systems

In SOAP RPC scenario, a requester wishes to tell the requester's language preference to the provider in order to receive SOAP fault messages in the requester's preferred language.

When a SOAP fault occurs, SOAP fault messages containing natural language descriptions of the error(s) are sent back to the requester. The requester usually wants to see error messages in the requester's preferred language(s) and data format. Currently the following mechanism is available with the HTTP binding.

Accept-language: The Accept-Language request-header field restricts the set of natural languages that are preferred as a response to the request.

Using Accept-language, a requester can notify a provider of the requester's language preference. A provider can then send SOAP-Fault messages in the requester's preferred language(s). If a SOAP message does not use the HTTP binding, how can a SOAP-Fault message detect the requester's language preference.

SOAP fault messages sent back contain text in natural language(s). SOAP fault messages should include xml:lang so that a requester can process SOAP fault messages based on the xml:lang identification.

Applies to: SOAP, or an extension of SOAP

Service provider needs to return fault messages in all available languages.

The Service Requester sends a SOAP document containing an error to the Service Provider. The provider generates a response containing a SOAP fault. In order to provide for multi-lingual response under the current design, the provider must return all available languages. The provider cannot know what languages (resources) are installed. Most programming environments do not provide functionality that enumerates which languages are actually installed, so the service provider must request every possible installed locale in turn in order to poll whether the string is available in that language. Since resources are often sparsely populated, this suggests significant processing overhead to loop over all possible locales, loading resources in turn.

Applies to: SOAP, or an extension of SOAP

Service requester must select a matching language from the list of fault reasons returned by the service provider.

The requester may be unable to (validly) match the returned text values to its current (end user) language.

If the requester is in locale "en-GB", then neither string will be considered a match for the current requester language preference. Although it is apparent to a human that en-US is a reasonable match for en-GB, automated processes are not permitted to make this assumption. ("en" would be a match for both "en-US" and "en-GB").

Applies to: SOAP, or an extension of SOAP

The service provider must return fault messages in all available languages, since it doesn't know the language of the requester.

Many operating environments are localized into a large number of languages (for example, Microsoft supports 33 languages in 120+ locales or regional variations). SOAP Fault reason messages might become substantial in size if every language must be returned.

Applies to: SOAP, or an extension of SOAP

The service defines a language preference in SOAP Header. The service is then chained.

Service "A" defines a header containing a language request field. This service is deployed.

Service "B" defines a service that includes a call to Service "A", but defines no header.

Requester calls service "B" with arguments that cause Service "A" to generate a fault. Because there is no standardized header format, Service "A" cannot generate the faultReason in the language of the requester.

Applies to: SOAP, or an extension of SOAP

FaultReason must substitute locale-sensitive data into text message.

Service "A" is defined on Provider "A". A fault is generated during invocation that returns a faultReason that includes locale affected values.

How does the provider perform the substitutions?

Applies to: SOAP, or an extension of SOAP

Service Oriented Architecture Derivative Patterns One Way Message

Applies to: SOAP, or an extension of SOAP

SOAP message variation if http or ftp or SMTP or RMI or IIOP (difficulty deploying in a single WSDL)

HeaderFault vs.Fault

Can a fault generated by the actual service return multiple language versions of itself? Or would the service actually generate faults only in the language that the service is running in (the environment or context of the server). If there were a "userLocale" or "userLanguage" defined in the service provider this wouldn't necessarily be an issue.

Caching affects results.

Locale affected fault evaluation.

Request-response versus connection-less.

Peer-to-Peer faults.

A sender wishes to send data to a receiver. The sender does not know the kind of formatting conventions that the receiver is using for various types of data. This usage scenario does not raise any requirements. It provides an example of best practice.

If the sender does not know the kind of formatting conventions that the receiver is using for a particular type of data, the sender has to use well-known, locale-neutral formatting conventions. XML Schema (Part 2, Datatypes) provides such such formatting conventions. Although SOAP can support various XML encodings, SOAP specifies the common data types such as SOAP encoding which is for general cases: e.g. RPC scenario for basic interoperability. SOAP encoding is based on XML Schema.

The following data types are related to date and time. They are built-in primitive types which are specified in XML Schema Part 2.

The above data types keep interoperability from a lexical analysis perspective. When a SOAP sender sends e.g. a date to a SOAP receiver using the above date type, both sender and receiver can interpret the date lexically.

On the other hand, date is accompanied with location. For example, 2003-05-31 in Korea is not exactly the same period of time as 2002-05-31 in France, but it is the same as 2003-05-31 in Japan. Date varies by time-zone which is related to regional government and geography etc. In processing SOAP encoding or XML Schema data types, it is necessary to distinguish locale-neutral data formatting and locale-neutral data semantics. Using SOAP encoding or XML Schema ensure locale-neutral data format, but does not ensure locale-neutral data semantics.

The following example is a SOAP message in SOAP encoding. Although all of the following data are locale-neutral formatting, the context of data differs from one location/culture to another.

SOAP transactions can use SOAP encoding/XML Schema to assure that there is no ambiguity in transactions between senders and receivers in order to keep lexical analysis interoperability. Additional attributes may be needed to assure the data semantics. Detailed scenarios are described in the next section.

Applies to: Web Services in general

A sender wishes to send monetary data to a receiver. Each of the monetary amounts has a specific currency. This usage scenario does not raise any requirements. It provides an example of best practice.

SOAP messages are sent to a receiver using XML schema data types such as integer, double, float, date, time etc. However, these data types may have locale sensitive semantics such as currency and location. In order to add data semantics, adding attributes is frequently used for XML messaging scenario.

Another option is to use a structure consisting of two elements for RPC scenario using SOAP encoding.

Applies to: Web Services in general

A sender wishes to send monetary data to a receiver. Sender and provider may use arbitrary currencies, but both sender and receiver do not use multiple currencies. They wish to set a default currency for one SOAP message.

Additional attribute is frequently used for monetary data exchange as mentioned above section. The following example shows multiple currency data transmission in a SOAP message.

Most regional services use a default currency instead of multiple currencies. For example, Japanese internal shopping uses JPY by default. The following is an example which has the default currency in SOAP header. It is possible to specify the default currency attribute in SOAP body instead of SOAP header.

Although adding parameter to SOAP body requires design change for service interface, adding default value into SOAP header does not affect services interface.

Applies to: Web Services General

A sender wishes to send locale dependent data to a receiver for regional SOAP messaging or RPC. The receiver needs to process the locale dependent data correctly.

If a Japanese sender sends date data to a Japanese receiver, the Japanese sender wishes to send data in Japanese calendar's date such as H13-5-31(H means Heisei era; see Appendix ) to the receiver.

Default is Locale neutral mode. If a sender and a receiver can handshake with each other using the same semantics of locale, sender can send a locale dependent data to a receiver, and the receiver can process the data consistently.

If WSDL can describe locale sensitive datatypes, locale negotiation mechanism can be described in WSDL. Is it applicable requirement for interface definition of WSDL?

There is a difference between data types such as telephone number, ZIP code, etc., which can be modeled as strings with patterns, and data types such as dates and numbers, where a connection with the value space (e.g. of XML Schema) may be desirable.

Applies to: WSDL, SOAP, or Localizable datatype

A service is defined using "Service Oriented Architecture Derivative Patterns Intermediary" as found in Web Services Architecture document.

Data is formatted for an end user by the receiver according to the end user's preferences and the system conventions. This usage scenario does not raise any requirements. It provides an example of best practice.

The receiver may format data in order to display the data in a user interface. Locale sensitive data formatting functions are widely provided by internationalization functionality of operating systems, programming languages, or applications such as word processors and middleware. Therefore, an application can format locale neutral data using built-in internationalization functions. The details of data formatting vary across different systems. Therefore, Web services themselves do not guarantee completely identical formatting on different systems.

Applies to: Web Services General

The sender formats data for viewing by an end user on the receiver side. The sender takes care of data formatting to assure consistency of presentation.

A receiver formats data according to the format provided by the sender.

Data sent by a sender is formatted by the receiver according to format(s) provided by the sender. This is different from scenario 2.13 and 2.14 in that the center of decision and the actual execution of the formatting are separated. Scenario 2.13 or 2.14 should be preferred because they are more straightforward, but this scenario may be chosen for various reasons such as: The sender wants to ensure consistent appearance, and the data may be used on the receiver side both for formatting and for further processing.

Data formatting rules should be sent to receivers together with data, in order to keep consistency self-descriptively, for user interface.

The following is a pair of float data and an example of numeric formatting rule.

Presentation result for user interface is:

The following example shows a way to send a formatting rule in SOAP header together with a float value.

Because a receiver receives a value in locale neutral decimal data together with formatting rule, the receiver can format the data for user interface self-descriptively.

Applies to: Web Services General

The service provider needs the locale of the sender in order to perform locale sensitive processing. There are three levels to this: Transport layer, service provider layer (SOAP Header), and service layer (SOAP Body) (we need separate scenarios for these)

Using an opaque identifier to identify a locale.

Same locale processing does not always return same result, because there are locale implementation differences among runtime environment.

A sender(requester) wishes a provider(receiver) to return a result of specific locale sensitive processing such as Java Locale, Windows Locale, or POSIX locale etc

Because user can customize locale, a sender(requester) wishes a provider(receiver) to return a result of locale sensitive processing based on the sender customized locale.

Applies to: A locale identification which distinguishes runtime differences or users customization.

Searching for Web services depending on language or culture.

Repositories and search-able meta-data (such as UDDI ) about Web services need to provide support for multiple language searches. Transport layer issues do not allow XML data structures to be used for resolution, except by reference (e.g. the receiver must down-load a separate resource asynchronously to "decode" the preference). Tags on this layer may be necessary in place of XML data structures.

There is no way for the service to find the best appropriate match when the user's request cannot be met.

If the sender specified "ja-JP" and "ja-JP" is not available at the receiver, what should the fall-back schema be?

Using a Web service to obtain some locale-related service, such as formatting, collation etc.

Some locale-related tasks are not easy to describe by an exchangeable data structure. Also, not all systems will have code for all locales. It may therefore be desirable in some cases to 'outsource' locale services.

Example 1: Formatting a date according to traditional Thai conventions (the full text of the formatted date is very long)

Example 2: Converting a date according to local rules that may not be predictable.

Example 3: Collation data can be very large, and collation may include additional domain-specific preprocessing in addition to the simple comparison of strings. It may therefore in some cases be more efficient to send the data to be sorted to another system.

Using Web services to update locale-related data that may change dynamically and/or in ways that are not easily predictable.

Some kinds of data needed for culturally sensitive operations is not easily predictable. Web services may be used to update such data, either by polling for updates or by sending out updates.

Example: Certain calendars depend on actually observed events, such as the actual observation of the new moon.

Example: Jurisdictions once in a while may change their rules for which time-zones they are in at which time of the year.

Issues: Scalability; requests may concentrate at specific times; polling may have to be repeated over and over without any actual updates.

If a Web service starts out uninternationalized and is later internationalized, it must be re-deployed as a separate service because the original service contract has changed.

The web services developer is solely responsible for supplying the fields, logic, and semantics that will be used to achieve i18n capabilities. Each service will vary in its approach and may not bother to supply a suitable mechanism. Without guidance from the client, assumptions have to be made that are unsuitable. For example, the locale of the server may be used to format the response. When the service is internationalized, the only option is to ask for locale as an additional input, changing the service contract.

There is an important functional and semantic difference between a field supplied in the actual service invocation (that is, as part of the data) and one supplied in the envelope (that is, as part of the protocol) because when supplied as part of the data, developers must always take care to create, populate, read, and process the fields. Internationalization of an existing service therefore takes the form of deploying a new service (since the inputs have changed).

By contrast, if locale and language preferences are part of the "context" (in the envelope, for example), the developer gains several advantages. First, both the provider and the service can read the locale and language preference. (The service must be provided with a specific API to obtain the locale and language from the provider, or it can be silently managed by the provider.) Services that require external environmental changes to activate their locale-sensitivity can have the provider perform this processing for them. Multiple services in the same "chain" can inherit the same locale and language context. Most important, though, the client-side environment can be optimized to provide the locale and language preferences of the end user automatically, without developers having to write code to obtain the values and populate the inputs of the Web Service. In addition, Web Service authors can add international or multi-language support to services after initial deployment without changing service descriptors (WSDL and XSD) that may already be in wide use.

There is no way for the service to communicate what language and formatting options are available.

If a Web service requires that a language, locale, or formatting preference in a service description (WSDL), how can the sender know what values will have meaning at the receiver. For example, POSIX locales for a C program are very different than (say) Windows LCID values.

As a result, developers of internationalized Web services (especially those that support multi-lingual operations - that is, servers that can provide responses in a variety of human languages and dialects) have to provide the ability to external users, whose platforms and programming languages may be maximally different than their own, to know what options the service supports.