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 Tuesday, 13 April 2004 23:13:41 UTC