- From: Martin Duerst <duerst@w3.org>
- Date: Fri, 31 Jan 2003 15:33:11 -0500
- To: "Mark Davis" <mark.davis@jtcsv.com>, "Addison Phillips [wM]" <aphillips@webmethods.com>
- Cc: "Web Services" <public-i18n-ws@w3.org>
Hello Mark, The document lists usage scenarios, i.e. little 'stories' of what one can do/what can happen. They are as concise or detailled as needed to make a point, or show a case. We have started to add recommendations, such as 'bad practice' or 'the way to do it' to some of them. I think you input could e.g. lead to two new ones, one showing the bad way to do things, and the other one showing a better way. Or we could merge the 'bad' one with a scenario that we already have. As for the Java example you gave, I think I have two comments. 1) It may be more difficult to pass complete error information around in a Web context than in a local context. Much more parties are involved, and many more things can go wrong. 2) SOAP faults may indeed be a rather bad design, because they punt on most problems by just offering some natural language text. I think our usage cases where a bit too much oriented towards showing the need for language negotiation, and not enough thinking about the general design principles. I have just spoken with somebody familiar with WSDL, and there the situation seems to be better, but I guess we have to check. Regards, Martin. At 10:04 03/01/31 -0800, Mark Davis wrote: >I would be glad to modify the text I supplied, though I'm not sure of the >desired format. It appears that the document is asking questions or pointing >out problems, not making recommendations. But it is hard for me to tell. > >Mark >________ >mark.davis@jtcsv.com >IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193 >(408) 256-3148 >fax: (408) 256-0799 > >----- Original Message ----- >From: "Addison Phillips [wM]" <aphillips@webmethods.com> >To: "Mark Davis" <mark.davis@jtcsv.com> >Cc: "Web Services" <public-i18n-ws@w3.org> >Sent: Thursday, January 30, 2003 21:32 >Subject: Re: Some comments on User Scenarios > > > > > > Hi Mark, > > > > Thanks for the comments. > > > > The particular scenario you note is part of a series that were > > constructed to help show the deficiencies in SOAP 1.2's plan to return > > SOAPFaults (basically, error messages) in an array of languages. > > > > You're text is correct. That's (part of) the point we were trying to > > illustrate. One problem with SOAPFault is that it isn't an XML data > > structure. It's just a string, pre-resolved. In order to enable > > multi-lingual operation, XMLP/SOAP just allowed you to resolve it (at > > generation time) into as many languages as you'd like. > > > > We should amend the usage scenarios to better illustrate these items. > > > > Would you care to massage your text into a suitable form? > > > > Addison > > > > Mark Davis wrote: > > > I was just reading through the document and had some comments: > > > > > > <citation> > > > > > > Service "A" is defined on Provider "A". A fault is generated during > > > invocation that returns a faultReason that includes locale affected >values. > > > > > > * > > > > > > "The date provided, 12 November 2201, was too late." > > > > > > * > > > > > > "The argument 12345.678 was too large." > > > > > > * > > > > > > "The argument 12345,678- was too small." > > > > > > How does the provider perform the substitutions? > > > > > > </citation> > > > > > > I'll include a bit of a document here that we could discuss: > > > > > > In general, error messages should be resolved as close to the user as > > > possible. Why do we make that claim? An error might be generated in the > > > bowels of a server module somewhere, where the end-user's language or > > > other information about the user is not known. If the error text is > > > composed at that point, it may be very difficult to eventually display > > > it to the user in the user's language. > > > > > > In the globalization architecture, the error is recorded at the error > > > site with as much information as possible, in as language-neutral a > > > format as possible. The actual production of the error text is delayed > > > until enough information about the user (such as the user's language) is > > > known, so that a correct translated error string can be looked up. For > > > example, the error might record an error key, a date, and a quantity. At > > > the point in the error processing where the user's language is known, > > > the error key is used to look up localized error text. The variable > > > information is inserted in the text in the appropriate place (this place > > > must be localizable!) and is eventually presented to the user. > > > > > > Example: In Java this could look like: > > > > > > // at the error site > > > > > > throw MyProgramException("Missing Records", new Date(), recordCount); > > > > > > // at the UI > > > > > > ...catch (MyProgramException exception) { > > > > > > String message = userResources.getString(exception.getMessage()); > > > > > > String resolvedMessage = MessageFormat.format(message, > > > exception.getArguments()); > > > > > > visibleErrorField.setText(resolvedMessage); > > > > > > } > > > > > > The resolution of error messages need not take place on the client side. > > > For example, a Web server can have the user's locale information at a > > > high level and also have locale-specific error text. The resolution can > > > take place in the server, resulting in the correct text in the Web page > > > served to the end user. This also requires there to be some client-state > > > information that the server can access, through an EJB or other >mechanism. > > > > > > An advantage of this approach is that the very same error message can be > > > formatted for different users in their own languages. It is in line with > > > the principle of exchanging language-neutral data where possible, and > > > formatting for the user as high in the process as feasible. > > > > > > This has a bearing on the notion of locale that has been discussed on > > > this list, as well. > > > > > > Mark > > > ________ > > > mark.davis@jtcsv.com <mailto:mark.davis@jtcsv.com> > > > IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193 > > > (408) 256-3148 > > > fax: (408) 256-0799 > > > > > > ----- Original Message ----- > > > From: "Tex Texin" <tex@i18nguy.com <mailto:tex@i18nguy.com>> > > > To: "Web Services" <public-i18n-ws@w3.org ><mailto:public-i18n-ws@w3.org>> > > > Sent: Tuesday, January 28, 2003 11:45 > > > Subject: use case requiring failure if locale is not available > > > > > > > > > > > Currently, if a requester specifies a locale and the service does not > > > > know of or has no provision for that particular locale, you get some > > > > default behaviors. The behaviors may be completely unrelated or > > > > inappropriate for the requested locale. > > > > > > > > However, if Web Services are to be used in an automated fashion, this > > > > may be unacceptable. > > > > > > > > For example, if a business prepares to produce a large run of reports > > > > overnight, and the locale of the user for each report is specified, > > > > there is no way of knowing which reports have been satisfactorily > > > > produced and can be given to the user and which reports will not meet > > > > the user's needs (wrong date formats, language etc.) and should not >be > > > > given to the user. (I am assuming the user is a paying customer of >the > > > > business.) > > > > > > > > > > > > It would be better in this situation for a web service to return an > > > > error indicating that the locale is unknown or not provided for and >to > > > > have the service request error. This would allow the business to >choose > > > > suitable alternatives in behalf of the users with failed requests and > > > > rerun the reports to get acceptable ones. > > > > > > > > This is of course an argument for an upfront negotiation of locale, >but > > > > if there isn't a negotiation and agreement on locale behaviors, >having > > > > the request fail when a locale is not supported is necessary for some > > > > services to be viable. > > > > It might also be the case that between the time of the negotiation >and > > > > the execution of the actual request a locale might be removed. > > > > > > > > My service uses another service for Chinese support, and after > > > > negotiating locales and accepting chinese, the chinese service goes > > > > off-line. If I continue processing it won't be in Chinese. It might >be > > > > better to fail the request. > > > > > > > > > > > > Some definition for a successful match and a failing match is needed. > > > > > > > > If en-us is requested and the service has en but not en-us, that >might > > > > be considered successful from a language point of view, but a failure > > > > with respect to date formats. (mdy vs dmy) > > > > > > > > On the other hand if en-us is requested and the service only offers >es > > > > or zh, then perhaps it should be failed. > > > > -- > > > > ------------------------------------------------------------- > > > > Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com > > > > Xen Master http://www.i18nGuy.com > > > > > > > > XenCraft http://www.XenCraft.com > > > > Making e-Business Work Around the World > > > > ------------------------------------------------------------- > > > > > > > > > > > > > > -- > > Addison P. Phillips > > Director, Globalization Architecture > > webMethods, Inc. > > > > +1 408.962.5487 mailto:aphillips@webmethods.com > > ------------------------------------------- > > Internationalization is an architecture. It is not a feature. > > > > Chair, W3C I18N WG Web Services Task Force > > http://www.w3.org/International/ws > > > > > >
Received on Friday, 31 January 2003 15:47:58 UTC