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.html 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 09:46:09 UTC