RE: Comments on I18N requirements for WS

Hi David,

Thanks for the note and for looking at our document. I have responded at
length below, inter-linearly. These are, of course, my personal thoughts and
not officially the position of I18N WG or WSTF. You'll get an official
response from the work group too, no doubt.

Best Regards,

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture.
It is not a feature.

> -----Original Message-----
> From: public-i18n-ws-request@w3.org
> [mailto:public-i18n-ws-request@w3.org]On Behalf Of David Booth
> Sent: Tuesday, May 11, 2004 11:56 AM
> To: public-i18n-ws@w3.org
> Cc: Martin Duerst
> Subject: Comments on I18N requirements for WS
>
>
>
> Below are comments on Requirements for the Internationalization of Web
> Services:
> http://www.w3.org/International/ws/ws-i18n-requirements-edit/Overview.html
>
> In general, I think this is a very interesting document and the
> requirements look reasonable.  I personally think I18N represents an
> excellent test case for WSDL 2.0 and SOAP 1.2.  It is tempting to
> foist the
> I18N problem off of WSDL and SOAP and onto the application
> domain, i.e., it
> is tempting to say that I18N is an application issue -- not a
> WSDL or SOAP
> issue.  But when you consider the fact that many applications will face
> this same need, and it makes sense to have a standard way of
> addressing it,
> then the question becomes: To what extent do WSDL and SOAP
> accommodate this
> need for I18N?  Ideally, I18N should be cleanly addressable using
> existing
> WSDL and SOAP extension mechanisms.  If our existing extension mechanisms
> prove inadequate for addressing I18N, then I believe we will have
> failed in
> our design of WSDL and SOAP.

I agree and I think our Task Force will also. The Usage Scenarios document
(which will have a new version published tomorrow or the next day) goes to
some length to illustrate this problem. Applications can be designed to use
existing SOAP and WSDL capabilities to be internationalized.
Interoperability requires standardization of the headers and body elements
exchanged, but this is still firmly addressable at the application level
with a "WS-I18N" type infrastructure.

Web service providers (service hosts), OTOH, may need something more
concrete. I think this can be handled using existing extension mechanisms,
but I also think this is a choice that WS technologies need to make
eyes-open. See for example Tim Bray's thoughts here:
http://www.tbray.org/ongoing/When/200x/2004/04/26/WSTandP


>
> Here are some editorial suggestions regarding the document.
>
> 1. Section 1 Introduction:
> Please use (or at least reference) the definition of "Web
> service" from the
> Web Services Architecture document:
> http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#whatis

The updated Usage Scenarios does already and this document will use this
definition when it is updated.

>
> 2. Section 2.3 R003 WSDL International Policy Feature:
> I'm having trouble parsing the sentence:
> [[
> Service providers need a way to provide information about a specific
> instance of a locale-affected Web service will execute or to
> differentiate
> instances of the same service.
> ]]
> Perhaps there is a word or two missing?

Yup. The missing word is "how". It is supposed to read:

 Service providers need a way to provide information about >how< a specific
 instance of a locale-affected Web service will execute or to differentiate
 instances of the same service.


>
> 3. Section 2.5 R005 Locale Identifiers:
> I am surprised at the statement: "there are no standards for identifying
> locales".  I don't know much about I18N, so please forgive me if
> this is a
> stupid question, but: Is this true in general?  (If so, I'm
> amazed.)  Or do
> you mean this statement only in the context of Web services?  If you mean
> it in general, then I see this requirement as much broader than for Web
> services, so I question whether it should be listed here.  OTOH, if you
> meant it in the context of WS, then I think you need a little more
> explanation of why there is a WS-specific requirement.

Welcome to the League of Amazed Developers ;-).

This is a general problem, which WS exposes: there are de facto standards
for identifying locales on the Web that rely on RFC 3066 language tags. But
these "standards" are not universal and in some cases controversial. There
is work under way in the I18N community to address these issues. Notably
there is a revision to RFC 3066 (draft-phillips-langtags-02.txt) that
provides more structure to language tags in general and an effort at the
Unicode Consortium (Common Locale Data Repository, or CLDR, see
http://www.unicode.org/cldr and http://www.unicode.org/reports/tr35) to use
the revised language tags to identify particular locales.

If you look at other Web technologies, such as XSLT or CSS, which you might
think are "locale-affected" and which use xml:lang to identify "the locale",
you'll find that each one really does mean language and not locale.
xsi:language is not locale and neither is HTTP Accept-Language. Web services
is the first W3C set of technologies in which actual software locales cannot
be avoided by careful wording and nudge-nudge/wink-wink inference of the
locale from the language preferences at hand.

In other words, this is a requirement that W3C (and thus the I18N WG) should
pay attention to the problem of locales and international preferences on the
Web. In the past, individual technologies like .NET, J2EE, etc. have used
the existing de facto standard of reading HTTP Accept-Language to create
their own individual solutions. But this flies in the face of Web service's
declared intention of being platform and environment neutral. For "WS-I18N"
to work, this problem must be addressed.


>
>
> --
> David Booth
> W3C Fellow / Hewlett-Packard
> Telephone: +1.617.253.1273

Received on Tuesday, 11 May 2004 16:20:43 UTC