Re: use case requiring failure if locale is not available

good comments. I sliced this up to make comments/responses more clear-

Addison Phillips wrote:
> 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.

Sorry, Perhaps my language confused the rationale for the automated
overnight run with the WS contents.
The purpose of calling the service is to create the reports. The service
is used to collect information returned in XML files which will be
further processed locally into a report or maybe accompanied by a style
sheet that makes the XML doc user friendly and readable as a report. In
any event the payload can always be an XML document.

> 
> 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???

Why does it need to be a hard failure as opposed to soft such as
returning the incorrect information.
If the web service was returning information to the navigation system in
your car and you either ended up in the wrong place or were shown a map
with all the labels in Chinese, you wouldn't care that the transaction
was successfully executed. Besides we have examples of those kinds of
hard failures. The point of the automation of a large number of service
requests is that there is no opportunity for human or individual review.
To support automated operation and large numbers of requests, services
need to have the ability to report when they are being asked to do
something they are incapable of and to error.
Ideally, if I request a service to give me a map, and it can only give
me one with Chinese names where I had indicated English required, I
would rather it failed the request, so that my process can consider
alterantive services with English support.

If a request comes to my site to place an order to california, and my
service does not know how to calculate taxes for california it should
not go ahead and create the order.

> >
> >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"?

ok. I agree. I provided the example without explaining the requirement I
was trying to justify. (Although perhaps this is a solution not a
requirement?)
The requirement is that the service requestor be able to indicate on the
request that the service specifically fail if it cannot match the locale
rather than utilizing a fallback locale which may not be acceptable to
the requestor.

I'll wait for a few more comments and then update the original text.

> >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. 

Yes. I thought I should recognize the alternative, even if unlikely.
There is some element of negotiation in that the services can be
distinguished and enumerated by locale. (i.e. a separate service can be
listed for each locale obligating the requestor to choose the
appropriate one or none.)


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.

yes, distributed is worst case.

> >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.

ok. I still need to read that choreography spec...


> >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".

yes. It's a problem that "locale" is too broad and ambiguous. A policy
statement is clearly needed because we can contrive examples where a
certain language is required and the currency doesnt matter and others
where the currency is important and the language doesn't matter. Simply
saying "must match locales" is meaningless, independent of the
suitability of values along the locale heirarchy.


-- 
-------------------------------------------------------------
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
-------------------------------------------------------------

Received on Tuesday, 28 January 2003 18:44:16 UTC