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

Well, it is now clearer. But they really screwed up error messages. That forces
all web services to be able to output every possible user's locale. And aside
from globalization, you want to be able to 'chain' exceptions.

Any hope of fixing the web services?

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- 
From: "Addison Phillips [wM]" <aphillips@webmethods.com>
To: "Mark Davis" <mark.davis@jtcsv.com>; <andrea.vine@Sun.COM>; "I18n WSTF"
<public-i18n-ws@w3.org>
Sent: Mon, 2004 Apr 12 21:22
Subject: RE: 4.7.5 I-008: Locale Sensitive Formatted Data in SOAP Fault Messages


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 10:06:55 UTC