- From: A. Vine <andrea.vine@Sun.COM>
- Date: Wed, 14 Apr 2004 10:44:01 -0700
- To: aphillips@webmethods.com
- Cc: I18n WSTF <public-i18n-ws@w3.org>
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:04:31 UTC