Re: FW: Issue 263 Response

Dear David,

Thanks for your response.

I'm well aware of the tardiness of I18N-WG's responses to you and again 
appologize for the lateness of these comments. It's not our intention to 
throw off your schedule or save all of our comments for the very last 
second. I don't think that these particular comments (263) require any 
textual changes to SOAP at this juncuture and we don't really have a 
solution on offer here, so I didn't expect anything more.

I should note that our responses were delayed by I18N-WG's rechartering 
effort. The Web Services TF was only formed in the last two months and 
this was the very first business we undertook at our first meeting, an 
FTF at the end of November. Despite the late date, the WSTF wanted to 
get our comments into your hands as quickly as possible, whatever their 
disposition.

In the future we hope to provide feedback and constructive commentary 
early in your process, where it will do some good.

Thanks,

Addison

-- 
Addison P. Phillips
Director, Globalization Architecture
webMethods, Inc.

+1 408.962.5487  mailto:aphillips@webmethods.com
-------------------------------------------
Internationalization is an architecture. It is not a feature.

Chair, W3C I18N WG Web Services Task Force
http://www.w3.org/International/ws



David Fallside wrote:
> 
> 
> 
> 
> 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:59:07 UTC