- From: Paul Deuter <Paul.Deuter@plumtree.com>
- Date: Sun, 7 Apr 2002 16:38:05 -0700
- To: "Addison Phillips [wM]" <aphillips@webmethods.com>, <www-i18n-workshop@w3.org>
Thanks Addison. I agree with most of your posting. It is somewhat idealistic, but I think it a goal that we should be striving for nonetheless. My expectation is that most data will be I18N neutral and the rest we will just have to accept the way it comes (probably in the locale of the service instead of the locale of the client). Let me give a concrete example that is faced when getting data from a Oracle database. Oracle is perfectly willing to execute a query according to the clients locale. All you have to do is set the locale first and then submit your query. You can switch locales for every query if you wish. If you have a webservice that is brokering requests from clients all over the world, then you might actually have to reset the locale before every query. My assessment is that the Oracle implementation is still insufficient to realistically expect webservices to take advantage of it. I think sending a separate command to set locale before every query is too much overhead and will not typically be done. Perhaps I am wrong, but this is my assessment. A better implementation would allow each query to carry the locale with it. Then you would not double the number of commands sent to the database. Suppose the SQL language had been designed with I18N in mind, then perhaps there would be a built in clause that would allow the locale to be specified with every query. That would be great. But locale is probably just one kind of information that might be useful and if the SQL inventors had done this, they might have felt obligated to add clauses for all sorts of environmental parameters that might affect a query. Perhaps instead of sending a locale id along with a SOAP request or some other webservice request, we should send a generic "environment id" that incorporates many different parameters. Perhaps a webservice would first allow the client to specify everything they want to about their enviroment (including locale) and have the webservice return an id that the client then includes in all subsequent requests. Just my two cents. -Paul Paul Deuter Internationalization Manager Plumtree Software paul.deuter@plumtree.com -----Original Message----- From: Addison Phillips [wM] [mailto:aphillips@webmethods.com] Sent: Friday, April 05, 2002 11:45 PM To: www-i18n-workshop@w3.org Subject: FW: [Distributed services] What is i18n on web services based web applications I originally posted this incorrectly on this list. Thanks, Addison -----Original Message----- From: Addison Phillips [wM] [mailto:aphillips@webmethods.com] Sent: Monday, April 01, 2002 10:18 AM To: www-i18n-workshop-request@w3.org; locales@yahoogroups.com Subject: RE: [Distributed services] What is i18n on web services based web applications All: I've been trying to catch up with the locales group and trying to make up my mind about their efforts (what is it? should I support/join in? is it germane to stuff I'm working on?). In general, I agree with Noji-san's message and the idea that this represents a different qualitative and quantitative problem than "locales" is working. I think I would state the problem differently: distributed systems such as Web Services need an I18n architecture. [As opposed to "we need an I18n architecture which can be used for ......] As a result, I don't think this actually requires a whole new locale model. Architecture, yes, but more along the lines of a protocol than an infrastructure. I fear that an infrastructure might not be accepted because it would not be simple enough (we would understand it in this forum, but the authors of SOAP et al aren't thinking all that much about it, as near as I can tell. There is an expectation that xml:lang already does this, I believe.). Perhaps I am misreading the intentions and direction of the locales group in this, but I don't see why I need the full range of locale data or preferences in an XML document, especially a Web Services document such as a SOAP envelope. Correctly structured data is nearly always locale neutral (the data model in SOAP for example sees to that). That said, there is a role for locale in XML and distributed systems. For example, the sort order of a collated result set (series of records) in an XML file should probably match the expected order of the client... I think what is lacking is: 1. A simple, well-documented standardized way of negotiating (indicating and fulfilling) locale preference on the web (can we formally co-opt Accept-Language, seeing as almost everyone uses it as both "locale" and "language choice"?) and especially in Web Services (possibly via an "xml:locale" tag). This is not the same thing as indicating the locale/format of returned data. These are two separate things. 1a. SOAP in particular needs to have a locale passing mechanism. There needs to be thought given to how multiple hops on the way to the destination handle locale, for example. I realize, from several long chats with our WS folks, that SOAP has gone out of their way to avoid protocols, but I firmly believe that the locale passing belongs in the envelope and I think it should be defined at the most abstract level so that the most implementations inherit good i18n behavior. Call me crazy. 2. A simple, well-documented standardized way of indicating language preference in XML (recall that xml:lang is an attribute, not a request--> using an attribute with a specific scope to imply the language desired seems haphazard, and what if you don't have an object that takes an xml:lang attribute in your request?). 3. The rules for handling these requests (chaining, negotiation, defaulting/fallbacks, what to do if no locale is requested, what to do if multiple locales are requested, etc.) would also be a useful adjunct (perhaps this is part of the locales group's project already??) The locales group appear to be defining both a complete i18n model (locale model) and an XML schema for transmitting the locale identifier or specific elements or facets of a locale. This is good work and useful. But I don't actually expect to need 99% of that. What I would like is something simple that can be promulgated to a large number of other WGs to get the desired result: hooks for our systems to use their already formidable multi-locale support with external systems. Thanks, Addison Addison P. Phillips Globalization Architect webMethods, Inc. 432 Lakeside Drive Sunnyvale, California, USA +1 408.962.5487 (phone) +1 408.210.3569 (mobile) ---------------------------------------- Internationalization is an architecture. It is not a feature. -----Original Message----- From: www-i18n-workshop-request@w3.org [mailto:www-i18n-workshop-request@w3.org]On Behalf Of Kentaroh Noji Sent: 2002?3?28? 4:08 To: www-i18n-workshop@w3.org Subject: Re: [Distributed services] What is i18n on web services based web applications David, thank you for your information. Because I have ever worked on locale as a member of an open source, I agree that locale is important i18n. However, the net message of my opinion on this mailing list is a little bit different. My message is: W3C i18n can define a model or an architecture of internationalization for web based client/server/distributed programming, because W3C works on not only XML based document processing but also web based callable programming interface such as Web Services. It may be impossible to mention about i18n on the specific technologies such as Java2EE, script languages for CGI etc, but it is possible to specify an conceptual i18n architecture/model of web programming including SOAP. I think that the appearance of Web services is a trigger to work for that. Thanks, Kentaro Noji Globalization Center of Competency, Yamato Software Lab., IBM
Received on Sunday, 7 April 2002 19:37:23 UTC