- From: Debasish Banerjee <debasish@us.ibm.com>
- Date: Thu, 16 Jan 2003 00:27:52 -0600
- To: Martin Duerst <duerst@w3.org>
- Cc: "Addison Phillips [wM]" <aphillips@webmethods.com>, public-i18n-ws@w3.org
Martin, My answers are embedded as <DB> ... </DB>. Thanks, Deb Martin Duerst <duerst@w3.org> To: Debasish Banerjee/Rochester/IBM@IBMUS, "Addison Phillips [wM]" <aphillips@webmethods.com> cc: <public-i18n-ws@w3.org> 01/15/2003 05:01 Subject: Re: [WSTF] My view... [long] PM Hello Deb, At 18:23 03/01/14 -0600, Debasish Banerjee wrote: >I believe, there is no need to deviate from the principle of 'not exposing >any contextual information in method signatures' in your "compareStrings()" >example. That 'userLocale' parameter in this particular example should also >be viewed as an implicit parameter derived from the 'invocation >internationalization context'. I'm not exactly sure here. There are many different paramenters that may affect string sorting, and an application programmer may want to be able to control many of them, including some language/locale-specific aspects. <DB> Yes, locale can definitely affect collation. But the application programmer can set up the desired locale (either programmatically or using the facilities provided by middleware) in the internationalization context. That locale from the i18nContext can be used for user-defined locale sensitive functions. Of course, if compareStrings() is a primitive operation in the implementation environment, the locale parameter (derived from i18nContext) should be supplied explicitly by the Web service implementer. Maybe I can clarify my position during the next tele-conference. This email exchanges sometimes can be rather inefficient. </DB> >Incidentally, your "compareStrings()" example highlights the 'life-cycle >management' policy for internationalization context. The >internationalization context probably has the shortest life-cycle span when >compared to other contexts. What would other contexts be? <DB> Transaction, Security, Co-relation (session) contexts can also be present in Web service invocations. </DB> >Within a user 'session', the >internationalization context can potentially be different during each >interaction with the Web service. For some kinds of operations and aspects, that would work well. But I can imagine that for other aspects, it wouldn't. Let's assume that as part of a session, the user retrieves different parts of a search result (the typical 1-20, 21-40,...). If this doesn't use the same sort order throughout, then it may retrieve some things twice, and others may get lost. <DB> Agreed. It is the Web service requester's choice whether to vary internationalization context within a so-called user session or not. Typically, the internationalization context does not vary during the lifetime of a simple (which does not also act as Web service provider) Web service requester. </DB> >4. We may need to express the management policies and attributes related >to 'invocation internationalization context' (and in general for other >types of contexts too) at various levels of granularity in WSDL >descriptions. The default management policy for internationalization >context must be 'runAsCaller'. What happens if the language/locale/context that the caller wants is not available? <DB> An interesting question. In the absence of inbound i18nContext, the Web service component configured to execute as 'runAsCaller' can effectively execute as 'runAsServer'. However, more sophisticated deployment policy can be suggested to define the 'default invocation internationalization context'. </DB> >All the management policies are to be enforced by Web service containers. >For container-managed instances, a Web service programmer should not able >to change the internationalization context programmatically. Why not? Assume that the Web service interacts with a DB that is in a particular i18n context, then the Web service program has to convert from the client context to the DB context. <DB> For enforcing the use of a disciplined programming model in component based managed environments. For this particular example, probably the service deployer can deploy the specific 'operation'(s) to execute under 'runAsSepcified'<DB's locale>. Programmatic alteration of middleware managed information in server-side components is not desirable; it can produce complex non-portable applications. Typically, if a complex server-side component (say C) needs programmatic alteration of i18nContext, it can be usually factored into two components C1 and C2. C1 is a simple component which is invoked by the service requester. C1 invokes C2, and C2 does all the interactions with DB. The (almost) dummy component C1 can be deployed under 'application-managed internationalization' policy allowing programmatic manipulation of i18nContext, and C2 can be deployed to execute under 'runAsCaller'. Again, for unusual circumstances, one can always deploy his Web service component under application-managed policy thereby having complete programmatic access to i18nContext. </DB> >In isolated >instances though, a Web service developer may want to exercise complete >programmatic control over the invocation internationalization context for >one or more components. The WSDL of those components can be associated with >something like "Application Managed Internationalization" policy. > >The management policy (container-managed internationalization or >application-managed internationalization) and attributes (runAsCaller, >runAsServer, Do we need 'runAsServer'? Any specific server would run in a specific context (e.g. Korean), or wouldn't it? <DB> 'runAsServer' is more flexible than 'runAsSpecified'. You can change the locale of your host from Korean to Japanese. The 'runAsServer' will then behave as Japanese. If you deploy the application on an Russian box, the component will behave as Russian. </DB> >runAsSpecified) can be specified at various levels at WSDL >components. WSDL need to define how the policy specified at a higher level >entity (say associated with a portType pT) affects the policy at a related >lower level entity (say operation oP contained within pT). >5. Do you think that 'time zone' should also be a part of >internationalization context? This is a very sensitive question. I know for >sure that some distributed architectures are already frustrated with the >Daylight Savings business and are embracing UTC. Still for user's >convenience, shall we propose to carry the time zone information along with >locale(s) in internationalization context? UTC-oriented Web service >components may simply ignore the time zone present in internationalization >context. I think there are several scenarios here (Kentaro, can you create some?): - For general time data, using explicitly marked (Z) UTC based dates/times is the best solution. Examples include international deadlines, international teleconferences, timestamps in DBs,... - For user interaction, it is often necessary to localize the time representation to the local time zone of the user or of the event. (the event e.g. for flight departure/arrival) Please note that the time zones in these cases are not ISO8601/XML Schema fixed offset time zones, but local 'politic' timezones with all the dailight savings rules,... attached. - For some cases of business scheduling/calendering, the above local ('politic') time zones have to be kept in the data (e.g. if two people agree to have a business meeting at 2pm on May 5, 2003, in Chicago, and Illinois would suddenly decide to change their daylight savings rules, then in terms of UTC, that meeting would move. - Any other cases? Regards, Martin.
Received on Thursday, 16 January 2003 11:33:11 UTC