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

"j2t-i0n-t2e-l10n"

Okay, I'm not proposing anything here. I'm pointing out that:

1. We could try to go for enumerating and number the possible provider level errors. The HTTP example is a good one, but the number of errors enumerated for HTTP is actually not that large. LDAP and SMTP are examples of the monster getting loose. To make the proposal someone would have to try to enumerate the number of fault states, define the mechanism for adding more, and so forth. It might be possible: no one has looked to my knowledge.

2. The middle section was to show that there is a mechanism already in place for the kinds of things Mark is talking about, although it suffers from requiring the developer to think in terms of j2t-i0n-t2e-l10n at design time. Really we ought to add a usage scenario for that, since the temptation is to resolve the faulty bits to a string in the service and be done with it. 

3. The much-maligned fault reason text element is something that we need to deal with carefully. It may not be possible to fix the mechanism outright for the reasons I tried to demonstrate (all the solutions require big changes to the underlying implementations on the service level, which is a big non-starter), but having the client and intermediary locales available at least lets you try to (I give up) j23-or-22n the messages into the appropriate languages (if available) at the provider level. Okay, the intermediaries can't re-resolve any more, but if the locale preferences chained back originally this isn't as big an issue. It is the equivalent of the web server formatting numbers and such like in a Web page before serving it. JITXL for me means "as late as reasonable", which isn't always all the way on the client or even on the server closest to the client in a distributed system. It's just as late as it reasonable--as close to both the resources *and* client as possible.

One more thing: of course there are Out-In and Out-only message exchange patterns where there isn't a client locale becuase the service starts the MEP, but these patterns don't allow for the Out message to be a fault, I believe.

IOW, this is more complex than it looks and fault reason text might not actually be fixable in a JITXL way, but at least we can show that it can be done *better* (which I think we do).

Make sense? Probably not, because my head hurts re-reading the message.

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: A. Vine [mailto:andrea.vine@Sun.COM]
> Sent: Wednesday, April 14, 2004 10:44 AM
> To: aphillips@webmethods.com
> Cc: I18n WSTF
> Subject: Re: 4.7.5 I-008: Locale Sensitive Formatted Data in SOAP Fault
> Messages
> 
> 
> Actually I prefer j23n to JITXL, unless you mean j22n. :-P
> 
> So, sorry but I can't tell what exactly you're proposing here, 
> Addison.  Are you 
> proposing a fault message structure, or a set of fixed fault 
> messages, or both?
> 
> My comment is that fixed messages are a very rocky road.  I 
> remember peripheral 
> discussions on doing something like that for SMTP and LDAP (I think). 
> Contentious and not productive.  Relative to other things one 
> could spend one's 
> time one, I suspect it's not worth it.
> 
> Andrea
> 
> Addison Phillips [wM] wrote:
> 
> > 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
> >>> 
> >>> 
> > 
> 
> -- 
> I have always wished that my computer would be as easy to use as 
> my telephone.
> My wish has come true. I no longer know how to use my telephone.
> -Bjarne Stroustrup, designer of C++ programming language (1950- )
>

Received on Wednesday, 14 April 2004 14:27:25 UTC