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

Hm...

That strikes me as a pretty fancy windmill to tilt at... so what the heck.

I agree that JITXL is a good thing that we want to promote. But I also recognize the problem inherent in "fixing" the Fault Reason text element. Let's take it in pieces.

1. Provide an HTTP-like numbering scheme. This could possibly work for errors on the provider level (indicating the types of faults that a SOAP processor can detect), but not for lower level faults generated within services or during invocation. At the provider level those all look the same: the service failed. But at the service level there are all manner of possibilities (e.g. insert list of all Java classes that are 'instanceof Throwable' here).

2. Provide structured messages. Actually, there is such a mechanism in WSDL and SOAP. It's the Interface Fault in WSDL, that is, a message that a service can send back with any structure you can describe with XML that is indicative of a fault within the service. Really this is what should be defined for any expected errors a service may emit (that is, if you write the service in Java and the method definition includes the keyword 'throws', then there should be an interface fault defined for each exception the method can throw and it can be JITXL in form, if only the developer can be induced to design it that way--enter WS-I18N with support for knowing what the ultimate and intermediary client locales are).

3. Provide for the unexpected. This leaves the odd messages (Classloading issues, NullPointerExceptions, abends of all types) that generate faults not mapped to Interface Faults and which the Provider must handle somehow. Since the type isn't known in advance it may not even be possible to resolve the message to anything except a string. 

I can't tell you how much effort I've expended at webMethods getting developers to wrap all kinds of basic exception classes with JITXL wrappers (for example, in JMS all exceptions take a (message) string as a constructor argument, so you have to be clever to wrap the exceptions up cleanly). This is where our friend the Fault Reason text element comes in. If your services and provider support JITXL, you want to take client (and intermediary's) locale preferences and use them to resolve the exception to a human readable string when you do the 'catch'. But I don't see a super complex mechanism here, since generally it is too late to extract the information necessary (in a catch the original data structure is gone--buried in the service's thread of execution, whereas you're in the Provider's code at this point).

References:

http://www.w3.org/TR/wsdl20-patterns
http://www.w3.org/TR/wsdl20/#InterfaceFault_XMLRep

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: Wednesday, April 14, 2004 6:46 AM
> To: aphillips@webmethods.com; andrea.vine@Sun.COM; I18n WSTF; Martin
> Duerst
> Subject: Re: 4.7.5 I-008: Locale Sensitive Formatted Data in SOAP Fault
> Messages
> 
> 
> Let's play blue-sky with that idea a bit. If the error message is 
> structured,
> *and* contains enough information that a further translation could still
> transform it, then we would have as much information as possible. 
> It could be
> translated without loss of information, so that it could be 
> further translated
> if necessary. Let's take a more complicated one:
> 
> Service A doesn't have the ability to localize for anything, just 
> emits English,
> but with enough structure to recompose. In this case, it does 
> know the user's
> locale (some services might not, so the goalLang might be added later.
> 
> <message xml:lang='en-US' id='dateToLate' goalLang='de-CH'>The 
> date provided,
>      <data xsi:type="xsd:date" seq='1' 
> value='2201-11-12'>11/12/2201</data>,
>      was too late for the
>      <data xsi:type="xsd:number" seq='2' value='1234'>1,234</data>
>      file(s).
> </message>
> 
> Service B can get it to German
> 
> <message xml:lang='de' id='dateToLate'>Fuer die
>     <data xsi:type="xsd:number" seq='2' value='1234'>1.234</data>
>     Datei war das eingegebene Datum,
>      <data xsi:type="xsd:date" seq='1' 
> value='2201-11-12'>12.11.2001</data>,
>      zu spa"t.
> </message>
> 
> Service C can get it to Swiss German (just for illustration, 
> since you'd use
> writing German -- and my Swiss is really rusty)
> 
> <message xml:lang='de' id='dateToLate'>Fuer d'
>     <data xsi:type="xsd:number" seq='2' value='1234'>1.234</data>
>     datei isch 's datum wo du iigaa haesh,
>      <data xsi:type="xsd:date" seq='1' 
> value='2201-11-12'>12.11.2001</data>,
>      z' schpoot gsi.
> </message>
> 
> There are still a number of things missing from this.
> - as you say, one may want a URL for the messages. If that is the 
> case, then you
> really would just translate at the end, however, not along the way.
> - one may want to allow parts to be translated along the way, 
> thus putting the
> current lang and desired lang on each item
> - the equivalent of a
> http://java.sun.com/j2se/1.4.2/docs/api/java/text/ChoiceFormat.htm
> l could be
> used so that the singular/dual/plural (etc) forms of words could 
> be used in
> accordance with numeric variables.
> 
> Mark
> __________________________________
> http://www.macchiato.com
> ► शिष्यादिच्छेत्पराजयम् ◄
> 
> ----- Original Message ----- 
> From: "Martin Duerst" <duerst@w3.org>
> To: <aphillips@webmethods.com>; "Mark Davis" <mark.davis@jtcsv.com>;
> <andrea.vine@Sun.COM>; "I18n WSTF" <public-i18n-ws@w3.org>
> Sent: Tue, 2004 Apr 13 20:12
> Subject: RE: 4.7.5 I-008: Locale Sensitive Formatted Data in SOAP 
> Fault Messages
> 
> 
> >
> > Some points here:
> >
> > First, I think just in time localization (actually late localization)
> > is great, and should be done wherever possible. However, changing
> > texts to translated versions (message localization) and formatting
> > various kinds of values may behave differently on a network, and
> > may therefore (have to be) localized at different places.
> >
> > I have discussed this in my 'World Wide Localization' paper in
> > Prague (http://www.w3.org/2003/Talks/0324WWL/paper.html).
> > See in particular "3.5 Message Translation". While the client
> > in almost all cases will have code to format e.g. dates to
> > his/her liking, the chance that all the strings for all the
> > applications the client is interacting with are available
> > on the client is not very high. This applies in general,
> > but in many ways even more so for faults, because they are
> > usually unexpected, system-dependent messages.
> >
> >  From our point of view, the ideal would be to have a list of
> > fixed error codes (such as e.g. in HTTP). I think the general
> > opinion on this in the SOAP community is that no list of codes
> > whatsoever could be comprehensive, and that therefore it was/is
> > better to not even try. In view of localization issues, we might
> > have to make them try harder.
> >
> > Another problem for JIT Localization is that while it can
> > potentially reduce language/locale negotiation, it may introduce
> > another kind of negotiation on a higher level: negotiating where
> > the localization should be done. For formatting, that may not be
> > necessary, but for message localization, it may well be. This
> > would be a general problem, but for faults in particular, any kind
> > of additional negotiation or network activity is a bad thing,
> > because the fault may be due to a network problem in the first
> > place.
> >
> > An alternative to simple error numbers would be more structured
> > error formats. Do we need such a format? Would it help? Could it
> > be used in other contexts? Are there similar formats already out
> > there?
> >
> > Mark gave a very simple example:
> > > > <error>someFault</error>
> > > > <date>2004-04-14</date>
> > > > <numberOfPages>1400</numberOfPages>
> >
> > I guess here 'someFault' may be an error number or a text.
> > For an error number, would it be better to have e.g. an URI
> > that points to a repository of localized messages, or some
> > other indirection or identifier that allows world-wide uniqueness?
> > For a text, would it be good to have a format that distinguishes
> > text and data, e.g. like such:
> >
> > <message xml:lang='en'>The date provided,
> >     <data xsi:type="xsd:date" seq='1'>2201-11-12</data>,
> >     was too late.</message>
> >
> > (the 'seq' attribute would serve to identify different data items,
> > which might be in different order in translated text).
> >
> > An example for a translated text format could then look like:
> >
> > <message-translation xml:lang='de'>Das eigegebene Datum,
> >     <data-substitution seq='1' />, war zu spa"t.</message-translation>
> >
> > Of course this is just a draft for a very simplified example.
> >
> > Regards,    Martin.
> >
> >
> > At 21:22 04/04/12 -0700, Addison Phillips [wM] wrote:
> >
> > >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
> >
> >
>

Received on Wednesday, 14 April 2004 13:53:11 UTC