- From: Addison Phillips [wM] <aphillips@webmethods.com>
- Date: Thu, 22 May 2003 10:19:45 -0700
- 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" pattern: 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 incorporation. Best Regards, Addison -- 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 http://www.w3.org/International/ws
Received on Thursday, 22 May 2003 13:28:35 UTC