Re: use case requiring failure if locale is not available

Hi Tex,

Thanks for supplying the use case. I have some comments inter-linearly 
below.

Addison

Tex Texin wrote:

>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.)
>
ap> Of course, part of the problem with this is that the example returns 
something other than a "normal" Web services payload. Generally a Web 
service returns an XML document that contains the resulting data. I 
think what you'll want to reference here is the (new-to-WS) attachment 
feature. Document attachments may be generated in a specific locale and 
language and then the matching problem might be an issue.

ap> You might instead look for an instance where a locale mismatch would 
actually be a failure condition for the processing. For example, 
something involving dates (where work days are computed differently per 
locale or where holidays are different) or possibly collation???

>
>
>
>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.
>
ap> I'm having some difficulty mentally separating mere "execution 
locale" and "implementation decision" here. It seems to me that the 
failure condition is probably one decided by the developer in business 
logic, or possibly in policy (as per Deb). Probably we should consider 
noting the "policy" aspect of "failOnMismatch"?

>
>
>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.
>
ap> Current WS architecture makes "negotiation" very difficult. The WSDL 
file indicates the way that the service is invoked. A SOAP document is 
generated to invoke the service directly from the WSDL file. The result 
of the service running is the returned SOAP response. There is no 
intervening handshake, so the WSDL file has to indicate all viable 
values and the SOAP document must choose the right one. This is exactly 
what you're describing in this last sentence. The WSDL file is generated 
once-and-only-once and may not reflect the up-to-the-moment system 
configuration. Perhaps it might be better to consider the ramifications 
of not having a locale matching policy. The default case would be 
similar to that of a single-user system: the requested locale cannot be 
met and the system falls back in an orderly, predictable manner. What 
you're highlighting, Tex, is that in a distributed scenario this has 
negative ramifications for certain implmentations.

>
>
>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.
>
ap> Chaining of services, though, is well-described in WS standards, 
especially SOAP. This is not so large a problem, since the Chinese 
endpoint will produce a SOAPFault and all Chinese processing will fail 
when the zh service goes offline.

>
>
>
>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)
>
ap> Again, maybe this is an implementation decision. I think it would be 
hard to describe a standard in other terms? This use case suggests to me 
that any "context" headers that get developed need to deal with both 
attribute exchange and "policy".

>
>
>On the other hand if en-us is requested and the service only offers es
>or zh, then perhaps it should be failed.
>

-- 

Addison P. Phillips
Director, Globalization Architecture
webMethods, Inc.

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 Tuesday, 28 January 2003 16:13:18 UTC