Re: Some comments on User Scenarios

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 13:47:18 UTC