FW: Issue 263 Response

Dear XMLP WG:

I appologize for the delay in responding to this issue: the I18N-WG (Web Services Task Force) [WSTF], which has recently reviewed your proposed solution to Issue 263, has only recently been organized and we reviewed your group's responses at our first meeting with an eye towards getting you feedback as quickly as possible.

We are concerned that your proposed solution to Issue 263 is incomplete or inadequate and so we are sending some additional comments. To help illustrate our comments, we have included several scenarios in our Usage Scenarios document, which you can find here: http://www.w3.org/International/ws/ws-i18n-scenarios-edit/

The scenarios that apply to this issue are 2.3 through 2.9.

Basically our concerns are:

1. Most operating environments do not provide a mechanism that will enable Web service providers to enumerate and generate all of the available languages, except by looping over the complete possible list of languages. 
   a. Expanding the SOAP definition to allow an arbitrary number of natural language messages will result in very poor performance. 
   b. On some platforms, it is not possible to loop over the installed locales because the list of locales cannot be obtained.

2. Sending back many or all of the available languages will result in very large or greatly expanded documents that provide limited or no additional utility.

3. Most operating environments do provide a mechanism for finding the best matching localized messages for a given (specified) language preference, but this cannot be applied without some language/content negotiation.

4. Of the major transports available for Web services, only HTTP offers any form of language negotiation (via the Accept-Language header). Since the transport is independent of the SOAP document itself and this header is generated by the specific system creating the connection, there are several chained, connectionless and multipoint WS scenarios in which an intermediary system may interrupt the flow of language preference from the requestor to the provider and back.

In other words, although the proposed revision allows multiple languages, implementers will not be able to use this feature to solve the problem or will only be able to use it in a limited way.

As a result we feel that, at a minimum, SOAP should either provide a mechanism for specifying the "international context" for a Web services interaction or this section should be modified to more emphatically state the need for such a mechanism. Such mechanisms might include:

- A general recommendation that each Web service provide a language negotiation mechanism and that this mechanism be used in providing human readable natural language text, such as SOAPFault reasontext attributes.
- A specific "Accept-Language" SOAP header along the lines of RFC3066 (which defines the HTTP Accept-Language header)
- An "International Context" SOAP header that provides extensible support for other i18n-related information

At issue is whether XMLP/SOAP should define this mechanism directly in SOAP 1.2 or whether XMLP/SOAP or I18N WSTF should work on defining this mechanism separately (and it be incorporated by reference into future Web services recommendations). We welcome your feedback on how to proceed with this issue: it is part of our charter to work on such issues.

We also have the following comments:

1. Specifically state that the first env:Text entry should be considered the "default" text, to be used when no match is obtained by the requestor with languages in the list. This ensures that the human reader always has some text available.

2. We note that the various drafts at http://www.w3.org/2000/xp/Group/, including the editor's copy (http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.html) do not seem to contain the proposed changes. We would like to opportunity to review and comment on these changes. The text in your proposed resolution appears to address our concerns except as noted above.

Best Regards,

Addison (on behalf of W3C-I18N-WG)

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 

=========
Message-Id: <4.2.0.58.J.20021124053643.04a19690@localhost>
Date: Sun, 24 Nov 2002 05:48:46 +0900
To: public-i18n-ws@w3.org
From: Martin Duerst <duerst@w3.org>
Cc: w3c-i18n-ig@w3.org
Subject: Fwd: XMLP Issue 263 Resolution


Dear WS I18N Task Force Members,

This is the first of a series of responses to last call
comments on the SOAP 1.2 specification that I sent in to
the XML Protocol WG on behalf of the old I18N WG a whil ago.

At the meeting today, the WS I18N task force went through
these responses to decide whether they should be accepted
or not, and coming up with some comments.

A list of the issues can be found starting at
http://w3c3.inria.fr/2000/xp/Group/xmlp-lc-issues.html#x256.

The way we want to proceed is that I forward the responses from
the XML Protocol WG to the public-i18n-ws@w3.org list, then
we will follow up with some proposed answers, and if we don't
get any comments on the list, we'll forward these back to
the XML Protocol list.

For this first message, I'm copying the I18N IG list, to make
sure that people on the Core Task Force (officially responsible
for reviews) can join the public-i18n-ws@w3.org list or ca
look at the archive to follow up on this discussion.

Regards,     Martin.

>Date: Fri, 02 Aug 2002 23:53:44 +0900
>From: Ryuji Inoue <ryuji@isl.mei.co.jp>
>To: xmlp-comments@w3.org
>Cc: duerst@w3.org, ryuji@isl.mei.co.jp
>Subject: XMLP Issue 263 Resolution
>
>Martin,
>
>The XML Protocol (XMLP) WG has decided to close issue 263 [1], which you
>originated, with the following resolution.
>
>
>The XMLP WG has decided to modify SOAP Reason element (5.4.2 in Part1)
>in the following manner:
>
>   - The Reason element information item has one or more Text element
>     information item children:
>
>       <env:Reason>
>           <env:Text xml:lang="en-US">wrong color</env:Text>
>           <env:Text xml:lang="en-GB">wrong colour</env:Text>
>       </env:Reason>
>
>   - The Text element information item has any number of character
>     information item children to explain the neture of the fault.
>
>   - Each Text element MUST have xml:lang attribute information item
>     (prefix of lang attribute information item MUST be "xml:").
>
>   - When there are multiple Text element information items, values of
>     xml:lang attribute information items MUST be unique.
>
>Applications can make multiple language versions of the fault text
>available using this mechanism. Applications could negotiate
>the language for the fault text using a mechanism built using SOAP headers.
>However we do not provide such a mechanism.
>
>
>We trust that this resolution satisfies your concern. If not, please
>contact the WG asap.
>
>[1] http://www.w3.org/2000/xp/Group/xmlp-lc-issues#x263
>
>--
>Ryuji Inoue
>Matsushita Electric Industrial Co., Ltd.

Received on Wednesday, 11 December 2002 19:06:11 UTC