Comment on WS-I18N WD

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Comment on WS-I18N WD

Mary Trumble



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
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Comment on WS-I18N WD

Felix Sasaki

Hello Mary,

Many thanks for your comments. Some replies below.

Mary Trumble wrote:

[snip]

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

I don't see a problem to describe SOAP headers ("WS-I18N"9 separately
from policy assertions ("WS-I18N Policy"). I'm also fine with writing
"everybody is free to use another framework than ws-policy" to describe
the capability of using a specific header. Actually that is what the
ws-policy spec says as well: the absence of a policy assertion does not
mean that the capability does not exist, it is just no information about
it available.

So I don't think that your proposal requires a change on our current
goals, or to put it different: I'm not really sure what you are asking
for ...

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

I think this issue will be handled in the LTLI document. ASAIK the
current way of thinking is to have only non-normative recommendations
about questions like "how many fields to use for a locale?".

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

I see your point, which is a very good one, and would respond with the
same as to 3.

Many thanks for your input again.

Felix