W3C home > Mailing lists > Public > public-i18n-ws@w3.org > November 2002

RE: XMLP Issue 263 Resolution

From: Addison Phillips [wM] <aphillips@webmethods.com>
Date: Mon, 25 Nov 2002 09:58:11 -0800
To: "Martin Duerst" <duerst@w3.org>, <public-i18n-ws@w3.org>
Cc: <w3c-i18n-ig@w3.org>
Message-ID: <PNEHIBAMBMLHDMJDDFLHAEHCGBAA.aphillips@webmethods.com>


In the FTF meeting we discussed the SOAP 1.2 Last Call Working Draft
extensively. In particular we looked at length at issue (263). Issue 263
relates to the language of SOAP Fault messages--the human readable text
returned by a Web service when there is an error.

The feeling of the task force members present was that the response of the
XMLP group to this issue, while an improvement, was inadequate and
unsatisfactory and it is our intention to frame some sort of response by the
time of our next (first) teleconference on 7 December. It is very important
that we respond to this issue quickly because of the fact that the SOAP 1.2
comment cycle nearing its end and the fact that the comments from XMLP-WG
are becoming somewhat stale.

This particular issue is clearly an illustration of several specific issues
not currently in the Use Case document for which I drew the action item of
creating the scenarios. I will post my results to the lists at the same time
that I send them to our editor, Kentaroh, in order to speed up public
comment and to spur additional thought about this specific matter and
additional useful commentary.

In briefly reviewing my notes on this issue, I have enumerated for myself at
least five use scenarios only involving language selection in SOAP
HeaderFault and SOAP Fault messages (!).

At the FTF, it was suggested that our reply to XMLP basically be along the
lines of "this is nice, but not enough". The problem that we foresaw at the
meeting was that XMLP will require from us a specific solution for how to
achieve language negotiation. The closest use scenario currently in our
working document is 2.9 (Locale Identification). The potential actions we
can take are:

1. Do nothing. It is possible to consider language negotiation beyond the
scope of the SOAP spec. Doing nothing in SOAP 1.2 would leave our Task Force
free to consider solutions and best practices at a later date.
2. Recommend that XMLP add a requirement that each binding provide a
specific solution to language negotiation, but not specify the solution for
any particular binding.
3. Recommend that XMLP provide a specific solution that applies to all SOAP

I will post the use case scenarios on-line shortly. In the meantime,
consider how this issue should be addressed.

On a personal note, if we choose the third alternative, we had best be
prepared to offer up the design for language negotiation in a SOAP document
or XMLP will (rightfully) hand us our heads and ignore our suggestion.

Best Regards,


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

> -----Original Message-----
> From: w3c-i18n-ig-request@w3.org [mailto:w3c-i18n-ig-request@w3.org]On
> Behalf Of Martin Duerst
> Sent: Saturday, November 23, 2002 12:49 PM
> To: public-i18n-ws@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 can
> 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 Monday, 25 November 2002 12:58:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:36 UTC