Re: Comment on WS-I18N WD

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

Received on Thursday, 23 November 2006 11:48:03 UTC