W3C home > Mailing lists > Public > xmlp-comments@w3.org > December 2002

Re: FW: Issue 263 Response

From: David Fallside <fallside@us.ibm.com>
Date: Thu, 12 Dec 2002 08:25:09 -0800
To: "Addison Phillips [wM]" <aphillips@webmethods.com>
Cc: public-i18n-ws@w3.org, w3c-i18n-ig@w3.org, xmlp-comments@w3.org
Message-ID: <OF1004101A.DA7B8488-ON88256C8D.0059E702@us.ibm.com>





Addison, your response is 4 months after we told you about our resolution
and only hours before we will request CR. Furthermore, it appears your
concerns can be handled by an extension (header or binding) as enabled by
the existing SOAP framework, and it is within your charter to define such
an extension. Given these points, I do not intend to interupt our CR plans
nor to ask the WG for more than their opinion on what other WG (WS I18N,
WSArch, etc) is the most suitable venue for creating the extension.

Regarding your last comment, the editor's copy of Part 1 section 5.4.2 (
http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.html#faultstringelement
) does contain the resolution we sent you. Due to an oversight on our part,
the actual spec text says that Text EIIs SHOULD have different values for
xml:lang rather than MUST have different values as we reported to you in
the resolution email.

Thank you,
David Fallside
Chair, XMLP WG




|---------+---------------------------->
|         |           "Addison Phillips|
|         |           [wM]"            |
|         |           <aphillips@webmet|
|         |           hods.com>        |
|         |           Sent by:         |
|         |           xmlp-comments-req|
|         |           uest@w3.org      |
|         |                            |
|         |                            |
|         |           12/11/2002 04:06 |
|         |           PM               |
|         |                            |
|---------+---------------------------->
  >------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                        |
  |       To:       <xmlp-comments@w3.org>                                                                                 |
  |       cc:       <public-i18n-ws@w3.org>, <w3c-i18n-ig@w3.org>                                                          |
  |       Subject:  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 Thursday, 12 December 2002 11:27:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:28 GMT