Re: Intermediary services replace 5.2.1, .2, .3

Hi,
I am at 781 863 1648 if you want to chat about it.

Yes it is introductory but the last para is supposed to be a (very generally
stated) scenario that clients and providers may have different i18n settings
which the intermdiary must negotiate carefully.

The diagram was supposed to help set the stage.

Probably will need sharpening though.

Maybe move the scenario heading to the last para in that section and leave the
rest as intro?

tex

"Addison Phillips [wM]" wrote:
> 
> Hi Tex,
> 
> I'm incorporating this text, but it's a little confusing. The scenario 5.2.1
> appears to be introductory text to the section?
> 
> Addison
> 
> Addison P. Phillips
> Director, Globalization Architecture
> webMethods | Delivering Global Business Visibility
> http://www.webMethods.com
> Chair, W3C Internationalization (I18N) Working Group
> Chair, W3C-I18N-WG, Web Services Task Force
> http://www.w3.org/International
> 
> Internationalization is an architecture.
> It is not a feature.
> 
> > -----Original Message-----
> > From: public-i18n-ws-request@w3.org
> > [mailto:public-i18n-ws-request@w3.org]On Behalf Of Tex Texin
> > Sent: mardi 30 mars 2004 15:12
> > To: Web Services; Tex Texin
> > Subject: Intermediary services replace 5.2.1, .2, .3
> >
> >
> >
> > 5.2 Providing Language and Locale Negotiation
> >
> > 5.2.1 I-020: Correlation of Data Between Services in Different Languages
> >
> > Scenarios in this section address the requirements of services that
> > employ intermediaries, as discussed in "Service Oriented Architecture
> > Derivative Patterns Intermediary" (in Web Services Architecture
> > document[WSA]).
> >
> > Editorial note Insert illustration. [Owner: Addison]
> >
> > In these scenarios, providers may offer services with support for either
> > differing or a variety of international preferences.
> > An intermediary service makes requests of these providers and
> > uses the results
> > to satisfy the requests coming from its clients.
> > The intermediary service may process and/or integrate the results from
> > different providers to create a new kind of service.
> > The intermediary service may cache its results, or the results
> > returned to it
> > by its providers, for reuse with subsequent requests.
> >
> > Clients requesting intermediary services can have different international
> > preferences.
> > Therefore the intermediary service must be careful with its algorithms for
> > determining when to reuse requests.
> > Proper tracking of source data locale and requester locale is required.
> > Also, correlation and/or aggregation of data may prove difficult if sound
> > internationalization principles are not used.
> >
> > 5.2.3 I-012: Caching
> >
> > If caching does not take international preferences into account,
> > it is possible
> > that
> > cached responses in the wrong language, format, or locale could
> > be returned.
> >
> > 5.2.3 I-012: Locale Negotiation in Intermediary Services
> > Alternatively, in scenario I-020, the intermediary service caches
> > fault reasons
> > and
> > other data returned from its providers in each of the languages
> > and cultural
> > conventions that are requested of it, tracking the locales of each result.
> >
> > Requesters of the intermediary service identify the desired
> > locale of expected
> > results.
> > With locale negotiation, the intermediary service can provide
> > results and/or
> > fault reasons that match the requester's international preferences..
> >
> >
> > 5.2.2 I-007: Locale Negotiation and Chained Services
> >
> > Chained services are a form of intermediary services.
> > A (source) provider defines a service that has a requirement for
> > a language or
> > locale preference. Another (intermediary) service provider,
> > defines the same
> > service
> > and invokes the first service to utilize its capabilities.
> >
> > The source provider defines an optional header containing a language
> > request field. If the intermediary service does not also define
> > the optional
> > header, then when it receives a request it cannot communicate the
> > requester's preferences to the source provider. The intermediary service
> > might indicate its own international preference(s) to the source
> > provider or
> > none, accepting default values. Unless, the description of the
> > intermediary's service declares its policy on addressing international
> > preferences, its users may have incorrect expectations of the results.
> >
> > 5.4 Soap headers
> > In a variation of these scenarios, a SOAP header can be used for locale
> > negotiation between each layer of requester, intermediary and service.
> > An example is a Web service wrapper to a legacy client/server application.
> >
> >
> > #################################################################
> > #################################################################
> > #################################################################
> > #####
> > #####
> > #####
> > #################################################################
> > #################################################################
> > #################################################################

-- 
-------------------------------------------------------------
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 Monday, 5 April 2004 14:10:49 UTC