W3C home > Mailing lists > Public > public-i18n-ws@w3.org > April 2004

RE: 4.7.5 I-008: Locale Sensitive Formatted Data in SOAP Fault Messages

From: Addison Phillips [wM] <aphillips@webmethods.com>
Date: Mon, 12 Apr 2004 21:22:11 -0700
To: "Mark Davis" <mark.davis@jtcsv.com>, <andrea.vine@Sun.COM>, "I18n WSTF" <public-i18n-ws@w3.org>
Message-ID: <PNEHIBAMBMLHDMJDDFLHIEMAHNAA.aphillips@webmethods.com>

I agree in general, Mark, but that's not the design of Web Services.

This is something we have been at pains to point out: Faults (the Web Service equivalent of a runtime error or exception) can only generate a text message, not a complex type (data structure) in the SOAP provided XML structure. These scenarios are our way of complaining about it (we corresponded about this previously, I think).

For example, a given service can have several "outbound" messages, some of which indicate success and some of which indicate an error of some kind (such as input out of range or record not found). These responses are under programmatic control of the service, please note, and can follow the pattern you describe in JITXL.

By contrast, a Fault is a runtime exception. It may be literally and exception thrown in the body of the service or it may be an error condition detected in the Provider (such as "service not found" or "malformed input"). As Andrea points out, Faults are different from SOAP messages indicating an error, because they can contain only a Reason element (a text element containing the human readable message).

In other words, the design of Web Services is such that all Faults are resolved to string where they occur at the level they occur.

What you're describing is a service that ends normally and returns a processing-controlled error. This can be done with Web Services and we should probably add a scenario showing it.

However, abnormal ends such as a thrown exception or an error detected at the Provider (rather than service) level--that is, errors not under control of the service's normal processing--are forced to return a Fault and these must be resolved to a natural language string as shown in the example at the level at which they occur. The string must be marked with xml:lang (yay!), but there is no default message, data structuring, or language negotiation provided. Hence the scenarios including I-008 and I-022.

Does that describe the problem more clearly?

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture. 
It is not a feature.

> -----Original Message-----
> From: public-i18n-ws-request@w3.org
> [mailto:public-i18n-ws-request@w3.org]On Behalf Of Mark Davis
> Sent: Monday, April 12, 2004 7:11 PM
> To: andrea.vine@Sun.COM; I18n WSTF
> Subject: Re: 4.7.5 I-008: Locale Sensitive Formated Data in SOAP Fault
> Messages
> 
> 
> 
> I disagree with this assessment. We all agree that the error 
> message -- when
> presented to the reader -- should be localized. Thus the user should see:
> 
> >      * "The date provided, 12 November 2201, was too late."
> >      * "The argument 12345.678 was too large."
> >      * "The argument 12345,678- was too small."
> 
> However, *where* the localization should be done is not so 
> simple. It should be
> closest point to the user where enough information is available 
> to formulate the
> message.
> 
> Thus Service A (where the error is generated) may not actually 
> have any locale
> information available. It might then simply send back something like:
> 
> "Use MessageFormat string associated with someFault, plus data 
> (in unlocalized
> form, e.g. XMLSchema datatypes):
> 
> ...
> <error>someFault</error>
> <date>2004-04-14</date>
> <numberOfPages>1400</numberOfPages>
> ...
> 
> This message hops from Service to Service until it gets to one 
> that knows (a)
> what the end recipient's locale is, and (b) what the MessageFormat string
> associated with someFault for that locale is.
> 
> For more info, see
> http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/jit_
> localization.html
> 
> Mark
> __________________________________
> http://www.macchiato.com
> ► शिष्यादिच्छेत्पराजयम् ◄
> 
> ----- Original Message ----- 
> From: "A. Vine" <andrea.vine@Sun.COM>
> To: "I18n WSTF" <public-i18n-ws@w3.org>
> Sent: Mon, 2004 Apr 12 19:06
> Subject: 4.7.5 I-008: Locale Sensitive Formated Data in SOAP 
> Fault Messages
> 
> 
> >
> > All,
> >
> > I think that the best arrangement of I-008, fault messages, and 
> I-022 would
> be:
> >
> > Move I-008 to be 4.3.3, or whatever it winds up being.  Rename 4.3 to
> something
> > like "Fault Handling" or "Fault Message Handling". Reword and 
> repunctuate
> 4.3.3
> > slightly as follows -
> >
> > -------------------------
> >
> > 4.3.3 I-008: Locale Sensitive Formatted Data in SOAP Fault Messages
> >
> > A service provider must substitute locale-sensitive data into 
> text messages
> when
> > generating faults.
> >
> > Service A is defined on Provider B. A fault is generated during 
> invocation,
> > returning a faultReason. In order to properly present values inside the
> > faultReason message, the locale must be known and locale 
> information must be
> > available.  For example:
> >
> >      * "The date provided, 12 November 2201, was too late."
> >      * "The argument 12345.678 was too large."
> >      * "The argument 12345,678- was too small."
> >
> > The provider should format substitutions in each message 
> according to the
> > language and locale of the message, not according to the locale of the
> provider
> > or service. In the case of Language Neutral or Service 
> Determined patterns, it
> > may not be possible to generate a message in the user's 
> preferred language (or
> > the preference may not be available). In these cases, the message should
> follow
> > the language preference of the provider or service host.
> >
> > For more information on locale related formatting, see I-022.
> >
> > --------------------------
> >
> > My reasoning is this:  People are going to look at fault 
> messages separately
> > from SOAP messages, because they are often from different 
> coding components
> with
> > different people working on them.  So I don't want to merge the 
> fault message
> > locale-based formatting with data formatting.  But the data 
> formatting example
> > has some additional information that they might want to take a 
> look at to get
> a
> > better concept.
> >
> > Andrea
> >
> >
> >
> 
Received on Tuesday, 13 April 2004 00:28:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:12:52 GMT