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

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.



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


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


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


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


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


>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 Wednesday, 15 January 2003 18:04:16 UTC