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