- From: Addison Phillips [wM] <aphillips@webmethods.com>
- Date: Wed, 14 Apr 2004 12:09:39 -0700
- To: <andrea.vine@Sun.COM>
- Cc: "I18n WSTF" <public-i18n-ws@w3.org>
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