]>
Requirements for the Internationalization of Web Servicesws-i18n-req-&year;&MM;&DD;&status;&DD;&month;&year;&Current;XML&Latest;Addison P. PhillipswebMethods

This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of current W3C
publications and the latest revision of this technical report can be found in the
W3C technical reports index
at http://www.w3.org/TR/.

This is a first Working Draft describing requirements for Web services
internationalization, for review by W3C members and other
interested parties. Although this is a first Working Draft , we think that the requirements described in this document are very close to the final requirements. The final target of the Working Draft is publication as a Note. We intend to use these requirements as input for the next phase of our work.

This document has been produced by the
Web Services Internationalization
Task Force of the
W3C Internationalization Working Group, as part of the
W3C Internationalization Activity.

Discussion of this document takes place on the public mailing list
public-i18n-ws@w3.org.
To contribute or comment, please subscribe by sending mail to
public-i18n-ws-request@w3.org
with subscribe as the subject. The
archive of this list can be read
by the general public.

At the time of publication, the Working Group believed there were no
patent disclosures relevant to this specification. A current list of
patent disclosures relevant to this specification may be found on the
Working Group's patent disclosure page.

This document is work in progress and does not imply endorsement by, or the consensus of the
members of the Web Services Task Force of the W3C Internationalization
Working Group. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

A Web Service is a software application identified by a URI ,
whose interfaces and binding are capable of being defined, described and discovered by XML
artifacts, and which supports direct interactions with other software applications using XML based
messages via Internet-based protocols. The full range of application functionality can be
exposed in a Web service.

The W3C Internationalization Working Group, Web Services Task Force,
was chartered to examine Web Services for internationalization issues.
The result of this work is the Web Services Internationalization Usage Scenarios document
.Some of the scenarios in this document
demonstrate that to achieve worldwide usability, internationalization
options must be exposed in a consistent way in the definitions, descriptions,
messages, and discovery mechanisms that make up Web services.

The following is a list of the requirements to address these issues.

Requirements
R001 SOAP Locale Feature

Problem Statement: Service providers and services need information
about the locale, language preference, time zone, or other international preferences
(such as currency, collation, etc.) of the requester.

Requirement:
A SOAP Feature (see ,
Section 5)
that provides the Web service provider international context information
(such as locale, language, or other culturally linked preferences)
about the requester and which the provider can use to tailor the language, invocation,
or operation of services or the operation of the provider
(such as language selection in the generation of Faults and so forth).

R002 WSDL Locale Feature

Problem Statement: Service providers need to indicate that the SOAP Feature
described in R001 is available for a specific service or collection of services.

Requirement: A WSDL feature that describes the international context SOAP
Feature described in R001.

R003 WSDL International Policy Feature

Problem Statement: Service providers need a way to provide information
about a specific instance of a locale-affected Web service will execute or to differentiate
instances of the same service. For example, Binding A executes in French, Binding B executes
in Japanese, and Binding C attempts to match the user's preferences.

Requirement: A WSDL feature that allows a service to describe a "locale
execution policy" for a service or a binding of a service, including any additional derived
information of interest to users of the service (allowing users the select the service and
binding that most closely matches their needs or to tailor the operation of the service via
header information). This feature must allow services to describe one or more languages or
locales available for a specific service and allow for a runtime user choice (language/locale
negotiation) when that is appropriate. It must also provide a way to indicate that a specific
service always executes using specific international settings or returns data in a specific
language.

R004 SOAP International Policy Feature

Problem Statement: Given the WSDL feature in R003, services must be able to
indicate which available choice to use when invoking a service (request) or which choice was
applied when the service actually executed (response).

Requirement: A SOAP Feature that describes the locale preferences the
requester wished to have applied to a service (in a request) or which were actually
applied to a service by the provider (in a response) as described in the Web service
description defined in R003. This mechanism may be the same as in R001.

R005 Locale Identifiers

Problem Statement: Although there exist standards for identifying languages
and language preferences on the Web, there are no standards for identifying locales or certain
other international preferences. These data structures are of interest in enabling Web services
and other Web applications for multi-lingual or global operation.

Requirement: A standard for identifying platform neutral international
preferences (that is, locale identifiers). One possible mechanism would be a standard
extension to the proposed extension of
RFC 3066 that describes international preferences.
Some of the items that such an extension would describe include:

Problem Statement: Automatic discovery of Web services needs to allow
users to find the same service in multiple languages and to find services that will meet
their specific language or locale requirements.

Requirement: Develop requirements for the discovery of Web services,
including via non-W3C standards such as UDDI.