Comment on WS-I18N WD

Since I'll be leaving the working group soon, I wanted to capture
some thoughts about WS-I18N before I go.

We've had considerable discussion about how to specify the I18N
preferences and capabilities of requesters and providers that are
discussed in the WS-I18N Requirements document and in the Web Services
I18N Usage Scenarios.  We've reached consensus within the I18N Core WG
and with other WGs that these attributes should be specifiable as policy
assertions under the WS-Policy framework.

One approach would be to produce a WS-I18NPolicy specification,
analogous to the WS-SecurityPolicy spec.  Alternately, policy assertions
could be added to the WS-I18N Specification.  Item 2 below explains why
you might want to have two separate documents.

So, here are some items to ponder, going forward.

1. Most importantly, what exactly are the policy attributes for
WS-I18N?

The WS-I18N Requirements document and the Usage scenarios contain the
collected wisdom from the original WS-I18N Task Force.  There should be
assertions to cover the requirements discussed in these two documents.
All those items related to capabilities and preferences should be
specifiable as policy assertions.

2. Does WS-I18N *require* support for the WS-Policy Framework?

Should specification of WS-I18N policies via the WS-Policy framework be
required or optional?

There are many existing proprietary or technology-specific ways to
specify I18N "policies" or "configurations" for Web services that
predate the WS-Policy Framework.

For example, for several years IBM has had a J2EE-based implementation
of an Internationalization Context that can be distributed using
either SOAP headers or Java-specific techniques.

There is an informal public description of the service, including its
SOAP header description here:
http://www-128.ibm.com/developerworks/websphere/techjournal/0409_tong/04
09_tong.html

While the SOAP headers are very similar to those described in the
WS-I18N WD, this implementation uses J2EE deployment descriptors to
specify "policies", such as whether the business method (i.e., the
service) should run under the locale and time zone of the caller (i.e.,
requester), or under that of the service's local environment, or under
some other configuration-supplied custom environment.

This is just one example of an existing implementation.  There are many
others.

If WS-I18N Policy and WS-I18N were specified independently, it would
be possible to comply with WS-I18N, without implementing a Policy
framework.  For products that do support WS-Policy, a WS-I18NPolicy
specification could describe how to specify WS-I18N assertions in a
standard fashion.

3. Should locale be specifiable with separate language and region
elements, as an alternative to a single locale identifier?

This is a  lesser issue, but I want to note it because there are
existing implementations that represent locale this way.

4. What about code sets?

There appears to be an aversion to including the code set as part of
the locale, but I'm noting it here because the issue has come up in
discussions that I've had with a rep from another company.  Although
we're moving toward universal code sets, there remains a need to express
capabilities and preferences for legacy code sets in some cases.  There
are probably some other similar items that are not generally considered
part of the locale, but may need to be, optionally, specified in some way.

------------------------------------------------
Mary K. Trumble
Tel: (512) 838-0094; T/L 678-0094
mtrumble@us.ibm.com

Received on Tuesday, 21 November 2006 09:52:25 UTC