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

I agree. Just so long as we get all of the relevent usage scenarios.

l2e-l10n?

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 11:21 AM
> To: aphillips@webmethods.com
> Cc: I18n WSTF
> Subject: Re: 4.7.5 I-008: Locale Sensitive Formatted Data in SOAP Fault
> Messages
> 
> 
> Erg.  Perhaps this is the next thing we can tackle after the 
> re-charter (or 
> during), but I'm not sure this can be solved before the 24th.
> 
> j23n but j19e
> j22n but j20e or in your terms JITXL8
> =:-o
> 
> 
> Addison Phillips [wM] wrote:
> 
> > "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- )
> >> 
> > 
> > 
> 
> -- 
> 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 15:16:04 UTC