Re: [WSTF] My view... [long]

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