W3C home > Mailing lists > Public > public-i18n-ws@w3.org > May 2003

Re: WSTF teleconference Notes

From: Addison Phillips [wM] <aphillips@webmethods.com>
Date: Thu, 22 May 2003 10:19:45 -0700
Message-ID: <3ECD06B1.30005@webmethods.com>
To: Martin Duerst <duerst@w3.org>
CC: public-i18n-ws@w3.org

Hi Martin,

That's great. I'm glad it went well and I'm glad you were able to go. 
Slides look good.

> A day or two ago, I started to feel that our distinction of
> - Localization-independent
> - Service-determined
> - Client-influenced
> is a very good one, but that it's quite difficult to put each
> Web service as a whole into one of these categories. 

That's true. A service that itself is language independent may still 
need the language preference when generating a fault (for example).

Another way to look at it would be that the pattern applies to the 
specific service (the method call that the SOAP processor eventually 
makes for you), not the SOAP cruft around it.

>So what I
> did in the talk was to say that these are aspects than can
> appear combined in a Web service. That easily allows to
> explain things such as the fact that faults should be
> client-influenced even in a Web service that basically
> is localization-independent. Also, it allowed to easily
> add another point, data-driven, which is quite important
> overall.

I'd like to hear a more complete explanation of what you think 
data-driven represents.

The example bullet points in the slides appear to be related to the data 
structure. E.g. the service's performance keys off which data is 
supplied. Is that what you had in mind? If I give you SI units, the 
service does something different than if I give you customary.

If that's the case, that looks like service-determined "service 
determined sub-pattern" (we need to rename that one!). A case could also 
be made that this is an example of 
language-neutral-but-still-internationalized. (Yes, you still have to 
i18n your language-neutral services ;-)). In the latter case, the 
service does something different because of a piece of data that it 
receives. The fact that i18n folks feel some affinity for one piece of 
data or another doesn't really matter. Infering the measuring system or 
currency from a language tag or locale is prone to error.

I should point out that you can have a language-neutral service (by this 
measure) that takes a language as an argument (inbound message data 
element). This is counter-intuitive, but what's important to the pattern 
is that the service, by design or policy, does not need information 
outside its parameter list in order to "do the right thing" for i18n.

For example, this Java prototype is (probably) the "language-neutral" 

public String formatDate(Date d, Locale l)

And this one is either client-influenced or service-determined (1st 
pattern) (depending on how the code is written):

public String formatDate(Date d)

I think we need to work on making this point clearer. As you may recall, 
the NYSE example in the scenarios doc we originally intended to use as 
an example of a different pattern!

Deb had some good comments in this regard that I need to memorialize for 

Best Regards,


Addison P. Phillips
Director, Globalization Architecture
webMethods, Inc.

+1 408.962.5487  mailto:aphillips@webmethods.com
Internationalization is an architecture. It is not a feature.

Chair, W3C I18N WG Web Services Task Force
Received on Thursday, 22 May 2003 13:28:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:38 UTC