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

Hi Deb,

thanks for the response. Comments inline below.

Addison

> -----Original Message-----
> From: public-i18n-ws-request@w3.org
> [mailto:public-i18n-ws-request@w3.org]On Behalf Of Debasish Banerjee
> Sent: Tuesday, January 14, 2003 4:23 PM
> To: Addison Phillips [wM]
> Cc: public-i18n-ws@w3.org
> Subject: Re: [WSTF] My view... [long]
>
>
>
>
>
>
>
> Addison,
>
> Thanks for drafting out a very nice initial requirement document.
>
> I have certain general comments and questions related to your document.
> Some of the comments in terse forms may be considered as candidates for
> inclusion in your list of requirements.
>
> 1.  Do we have to treat 'language' and 'locale' separately? As you very
> mentioned, this can generate unnecessary confusion. Can we consider
> 'language' to be an optional part of a 'locale'?

Yes, from the point of view that language is an aspect of locale. However,
there are two arguments for keeping language preference separate:

1. Language negotiation mechanisms already exist and are fully documented. A
new locale negotiation mechanism must co-exist with these language
mechanisms. Therefore, although locale contains a language preference, we
need to say how that overrides or is overridden by the language mechanisms.

2. Some folks (not necessarily me) think that language negotation should be
kept entirely separate from processing locale.
>
> 2.  Instead of terms like "Accept-Language', 'Accept-Locale',
> 'Content-Locale', I prefer the use of the term 'Internationalization
> Context'. A 'context' is (a) system level information, and (b)
> transparently provided and managed by middleware infrastructure. A
> system-level data should not appear in any application-level method or
> operation signatures. To maintain remote-local transparency in distributed
> heterogeneous managed environments we need to use contextual system-level
> information containing locale(s), etc. I view this particular category of
> contextual information as the 'Internationalization Context'.

Agreed, but I used this shorthand to draw a parallel with existing HTTP
protocol, which others seem to understand readily.

>
> Note that in your example of "addInts(...)" we are actually using
> 'internationalization context', which is transparently
> propagated, managed,
> and made available (using APIs) by the so called "Web service
> container'--the middleware.

I think that was my point when I said "It is unnatural to force the
developer to specify the method as:", that in normal programming you do NOT
want to clutter things up with extra locale objects all over everywhere. You
only want to declare a locale object when you normally would declare one
(that is, the locale is actually significant for your data structure or
process)

For WS tools that take existing code and "web service-ize" it, this makes a
lot of sense: you don't have to rewrite the code. For WS authoring tools
(e.g. you write the method as a Web service ab initio), it promotes a clean
practice that is easily understood.

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

There is no need, you're right, as long as you want to write a service that
uses the "user's default locale" to perform the process. By contrast, one
might wish to write a locale-affected service and let the user override the
locale. Perhaps compareStrings is a poor choice. Maybe a more complex
example is called for. Say "localeAffectedAddInts" which takes two
locale-formatted strings? I don't know off-hand, but my point was that IF
the developer makes a design time decision to provide a locale as part of
the interface, THEN it is for the express purpose of overriding the default
user locale.

It puts the locale in the service's "contract" so that there is no guesswork
about what the service is doing.

In webMethods tools, for example, we actually have special locale values for
"user", "server", "null" (locale-neutral, like C or POSIX locale), and so
forth, that can be applied to pass the context value to a service that takes
an explicit locale argument (that is, so you don't have to specify the
user's locale, for example, at design time, you just get it from the
service's "InvokeState"). This is DIFFERENT than a service that takes no
explicit locale argument and just uses its invocation state/i18n context to
handle problems like resource management and the like.

>
> 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. Within a user 'session', the
> internationalization context can potentially be different during each
> interaction with the Web service.

Hm... each interaction with a Web service is a separate session anyway,
unless you use something like the EWS framework. Even in the context of
"service flows" (like orchestrated with BPEL4WS or whatever), each service
is separately invoked and has its own i18n context.

Note that in terms of "larger orchestration" of Web services, you probably
a) want a consistent user context and b) most Web service "client" systems
will probably be reading the value from the operating environment or some
static configuration anyway... ;-)
>
> 3.  Whether contexts will be carried in headers (for SOAP) or
> trailers (for
> XYZ protocol) is an issue related to binding. First we need a formalism to
> express contextual information in WSDL fundamental entities like
> 'serviceType', 'portType' etc. WSDL binding specifications can then define
> the exact mechanisms for propagating various contextual information
> including our internationalization context. For SOAP-binding of WSDL,
> certainly all the contextual information should be carried in
> SOAP headers.

Agreed. My concern is whether we are JUST doing SOAP, or whether the scope
goes all the way to, say, HTTP human-interactive (or somewhere in the
middle.......)

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

I disagree. For >>International aware<< systems, yes, that would be the
case. But the default now is UNaware systems and these will default to
'runAsServer'. Hence, I think the default is 'runAsServer' unless the
container a) supports the i18n context and b) you send it one.

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

I agree that the Web service programmer should not be able to change the
context itself programmatically. However, the programmer may 'ignore' the
context and use another explicit value in written code. Or the service may
override the value when invoking other services or in the return values. The
nature of Web services, though, suggests that this isn't much of an issue.
The next SOAP document received begins a new transaction or, at least,
interaction in the sequence of transactions and it can, of course, have an
i18n context of its own.

>
> The management policy (container-managed internationalization or
> application-managed internationalization) and attributes (runAsCaller,
> runAsServer, 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).

Generally the policy and attributes are intrinsically related to the actual
service's implementation. For the non-WS folks: a "portType" in WSDL is a
collection of "operations". An "operation" is a sequence of inputs (receive
SOAP doc) and outputs (send SOAP doc). A "binding" associates a "portType"
with a specific transport protocol.

I agree that these details need careful thought through. Part of me is of
the opinion that i18n attributes might occur down at the "message" level,
since that is generally closest to the the actual method implementation. The
context exchange itself would be defined at a higher level, perhaps.
Consider:

        <wsdl:message name="addIntsInput">
                <wsdl:part name="var1" type="xsd:integer"/>
                <wsdl:part name="var2" type="xsd:integer"/>
                <i18n:policy value="runAsCaller"/>
        </wsdl:message>

>
> The management policy and attributes should be made available at Web
> service discovery namespaces like UDDI. An Web service client should be
> able to browse UDDI namespace and base its selection of a Web
> Service using
> its internationalization context (probably along with other contexts too)
> management policy and attributes. Certainly for a general Web service
> client, the 'runAsCaller' deployment attribute of a web service
> W1 promises
> more towards distributed localization when compared with 'runAsServer'
> attribute for a similar Web service W2. If all other factors are the same,
> the Web service requester may select W1 for its superior
> internationalization capability.

I somehow doubt it. What's more interesting at the UDDI level is whether the
service is "available in my language", has a description "in my language",
and offers processing that is useful to me in my locale or context. A Web
service that runsAsCaller but returns everything in Chinese is less useful
to me than one that is hard coded to return English---but only because I
don't speak Chinese, eh?

I think it more likely that users will want a different quality of
information about Web services in registries.

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

No, I don't. Although I have invested significant time in TZs of late.
Heaven knows that there are few corners of i18n that confuse developers more
than how to deal with TZ!!

At issue here is that transporting "zone affected" dates and times is just
about like transporting "locale affected" data formats. You wouldn't send
"1.234,45" as a number. Sending "18:35" as a time is just as bad.

Dates and times in WS should use the ISO8601 (explicit, Gregorian, long)
formats wherever possible. Ideally, we would have millis-since-epoch-UTC
like java.util.Date, but I digress.

Telling me your time zone does no good. I don't want to perform costly, time
consuming conversions when xsd provides explicit formats and let's you deal
with problems like DST changes.

Okay, I can see how some systems might require TZ to be complete and TZ is
orthogonal to locale, so if we are going to communicate using TZ affected
formats, we need a separate data field.

>
> 6.  To my knowledge there is no standard definition of locale. The
> RFC3066-type tags is probably suitable for modern programming environments
> like Java,  C#, ICU, or the ANSI C++ library (I am not too sure
> about it, I
> have to double check). POSIX, and XPG4 (the classical C and C++
> internationalization environment) can not natively provide a multi-locale
> enabled (ML) environment anyway. I do not know about native Macintosh
> environment. Can a native Macintosh programming environment be ML enabled?

Nope. There is no standard definition. RFC3066 is actually something I'm
wary of, since it invites the confusion with language tags (already a mire
of confusion). Most modern programming environments, such as those cited,
can get by or do something meaningful with 3066 tags, but there are all of
these annoying exceptions for each one.

>
> For systems which do not recognize RFC3066-type tags, can we go for
> pluggable adapters? For interoperability, the adapters will be used by Web
> service containers for converting (often approximately) RFC3066 type of
> locale data to the native locale and back.

Like Microsoft's extension DLL, for example? I suppose. But I think some
effort should go into allowing the extra, non-3066 information to flow along
without getting lost. I have several examples we can discuss...
>
> I guess we can discuss these and other issues in our next teleconference.
>
> Thanks,
>
> Deb
>
>
>
>
>
>                       "Addison Phillips
>
>
>                       [wM]"                     To:
> <public-i18n-ws@w3.org>
>
>                       <aphillips@webmeth        cc:
> Debasish Banerjee/Rochester/IBM@IBMUS
>
>                       ods.com>                  Subject:  [WSTF]
> My view... [long]
>
>                       Sent by:
>
>
>                       public-i18n-ws-req
>
>
>                       uest@w3.org
>
>
>
>
>
>
>
>
>                       01/13/2003 06:09
>
>
>                       PM
>
>
>
>
>
>
>
>
>
>
>
>
>
> Folks:
>
> This email outlines my approach to the locale/language issue we discussed
> in the last telecon. It is somewhat long.
>
> I consider "locale" to be an environment setting or settings that govern
> how data is (to be) processed. Language preference may either be an aspect
> of "locale" or may be a separate environment setting. There are cases
> (described below) in which the locale is also a data element which is part
> of the processing, but this is a special case and I think it is important
> to deal with it as such.
>
> In traditional software, the developer doesn't need to explicitly obtain a
> Locale object or setting in order to write internationalized code. The
> default behavior of locale-aware functions obtain and use the locale from
> the system environment. Yes, the developer must call the correct functions
> or methods, but s/he must only obtain a locale when the desire is to
> override the user's preference (the default).
>
> A notable failing of enterprise and client-server architectures has been
> the failure to simulate this relationship and provide
> multi-locale support,
> that is, a server that can process data for clients running in different
> locales at the same time. Well-designed "ML" client-server systems
> negotiate the locale for each client session with the server and
> the server
> tracks and processes data with the client's preferences.
>
> Web services are a form of client-server architecture in which the "Web
> service container" calls a function or method for the "client". There is a
> "service description" (WSDL file) that describes to the client
> what data to
> pass, where the container server is, what protocol(s) to use, and
> so forth.
> The client uses the service description to build a SOAP document
> containing
> the necessary fields (required and optional) and sends it to the
> container,
> which invokes the actual service with the data.
>
> If there is a failure, a SOAP fault is sent to the client. The failure can
> be in either the container or in the service itself. Depending on the
> nature of the service, the container may or may not return a SOAP document
> with data or a result.
>
> Now the problems here are:
>
> 1. When designing the actual service (the underlying method or function),
> the developer should not need to deviate from standard i18n practices. If
> the service's data model doesn't require a locale, then the developer
> shouldn't have to artificially provide one just to internationalize the
> service. Consider a Java method that adds to integers together:
>
>   public int addInts(int var1, int var2)
>
> The method is not locale affected, nor does it take or return any locale
> affected data types or values. However, the method may return an error
> message ("loss of precision" or "integer overflow", for example), so it
> needs to provide for localization. It is unnatural to force the developer
> to specify the method as:
>
>   public int addInts(int var1, int var2, Locale userLocale)
>
> The Web service container should provide this functionality.
>
> 2. When generating WSDL for a service (as part of deploying the
> service), a
> multi-locale enabled container may add its own proprietary header value
> that allows the client to specify the execution locale. Since the
> extension
> is proprietary, it may not be possible for the client to
> accurately provide
> a suitable value to the container. Likewise, the client may not be able to
> interpret the results. Consider some WSDL generated by the product I was
> using at the FTF. As a Java product, it rendered java.util.Locale objects
> by using the constructor that takes three strings: "language", "region",
> "variant". How would a C#, C++, or perl program invoke this service
> accurately?
>
> In other words, a proprietary solution may not be interoperable and may
> expose the implementation to readily.
>
> 3. If the service container generates its own header, this may conflict
> with a service that reasonably does require a Locale argument to
> invoke it.
> Consider this Java service:
>
>    public int compareString(String var1, String var2, Locale userLocale)
>
> The userLocale allows the client to override the default locale to get the
> result. If the container also generates a proprietary header, the client
> may have a hard time implementing the service correctly. And the semantics
> may vary for "locale".
>
> 4. If the service is not internationalized or has limitations on its
> invocation (consider many legacy host systems), there is no way
> to tell how
> the service was actually executed or to know about these limitations.
> ---
> Aside: These last two scenarios Deb described in an off-list email last
> week. These are "runAsClient", "runAsSpecified" and "runAsServer"
> scenarios, Deb.
> ---
>
> IMHO, the "big picture" (requirements) here are:
>
> 1. Web services needs a non-proprietary negotiation mechanism for locale
> and language preference.
> 2. The mechanism should be based on locale tags or an XML
> "locale" or "i18n
> context" data structure that is platform neutral.
> 3. The mechanism should be part of the service invocation context (e.g. in
> the header or envelope, not the payload or body). Implementers should
> create APIs and runtimes that use this as intended (described above), but
> non-i18n implementations will merely ignore it or get
> locale-of-the-server.
> 4. Services that need a locale "object" may use the tags/structure in the
> body (e.g. in the service's "contract") to pass locale information.
> Developers can thus provide "i18n demo" services ;-).
> 5. The mechanism must be able to deal with both client preference
> ("Accept-Locale") and server capability ("Content-Locale"). It
> must have an
> analog for the "null" (neutral, POSIX, C) locale.
> 6. Web services providers and client vendors should be able to count on
> this mechanism being available and invoke services with it without knowing
> if the back-end system can service their requests. This is a way of saying
> this is not "mustUnderstand", I guess.
>
> I'm on record as favoring tags over an XML structure, but I'm
> willing to be
> persuaded (and try persuasion ;-)). I have use cases galore from
> webMethods
> that relate to the various aspects of the above.
>
> Some things to think about:
>
> --RFC3066 language tags (that is xx-YY) are sufficient for
> identifying Java
> locales and possibly C# CultureInfos, but not for POSIX, C/C++, Mac, and
> other native programming environments.
>
> --There is bound to be confusion about language ("Accept-Language") and
> locale.
>
> I have lots more to say, but let's start with this. Is this an accurate
> description of what our requirements should be? How can I flesh out the
> problems better?
>
> Best Regards,
>
> Addison
>
> Addison P. Phillips
> Director, Globalization Architecture
> webMethods, Inc.
>
> +1 408.962.5487 (phone)  +1 408.210.3569 (mobile)
> -------------------------------------------------
> Internationalization is an architecture.
> It is not a feature.
>
> Chair, W3C-I18N-WG Web Services Task Force
> To participate see http://www.w3.org/International/ws
>
>
>
>
>

Received on Tuesday, 14 January 2003 21:52:01 UTC