Re: Some comments on User Scenarios

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