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

Yep. Those scenarios appear in our document already. Under separate cover I sent you a note about the hope of fixing things.

Addison

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: Mark Davis [mailto:mark.davis@jtcsv.com]
> Sent: Tuesday, April 13, 2004 7:07 AM
> To: aphillips@webmethods.com; andrea.vine@Sun.COM; I18n WSTF
> Subject: 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 11:59:37 UTC