My POV [long]

Hello, 

Addison wrote>>
>Action Items:
>
>1. Martin: will follow up with Russ Rolfe in case 
>MS has any space in Prague for an FTF. 
>This is a low priority item.
>2. Team: write up and send to list a "position" 
>on the locale problem (See notes below for 
>what that means). Due prior to next meeting.

The following is my POV descriptions. 

My view focuses on interoperability. If introducing RFC3066 style lang tag 
as it is to Web Services Locale model, a result of Web Services loses 
functional interoperability due to locale implementation differences of 
service runtime environment. Introducing locale model for web services, we 
need to consider a framework to keep i18n functional interoperability in 
heterogeneous Web Services operating environment. The following 
description is current my concerns about Language/Locale/i18n context 
management. 

* * * * *

1. Language and Locale

Problem: Because the most of basic Locale naming rule is a pair of 
language and region, Language is usually a part of Locale name. On the 
other hand, Language tag "en-US" means American English, and Locale 
"en_US" means language: English(US), and the country: United States. What 
is the difference between locale and language? 

My view: Language is a part of Locale if they are mainly used for messages 
of user interface. However, if locale links other data processing such as 
collation, data exchanging etc,  locale becomes different semantics from 
language. For example, "Invest $100,000" is an en-US messages and it can 
be generated from en_US locale sensitive functions such as Java 
NumberFormat, ResouceBundle and the default currency.
 
On the other hand, data "$100,000" is English message, but it may be, or 
not related to default currency of en_US locale because currency is 
attributed to actual monetary data instead of locale, according to some 
application scenarios. For example, when monetary data $100000.00 is sent 
from an account of a bank of US(en_US) to an account of bank of 
France(fr_FR), it must be $100000.00 as it is, or it is exchanged into 
€93773.45 by an exchange rate. An account user which prefers French 
culture wants to see the monetary data such as "100 000,00$" or "93 
773,45€". An account user which prefers American culture wants to see the 
monetary data such as "$100,000.00" or "€93,773.45". 

In summary, 
en-US message
"Invest $100,000.00" 
"Invest €93,773.45"
en_US default currency: $


fr-FR message
"Invest 100 000,00$"
"Invest 93 773,45€"
fr_FR(after 1999) default currency: €

The most of existent locale model focuses on data formatting for UI, or 
sensitive functions in stand alone operating environment. It does not 
focus on how to exchange data which is affected by locale, and how to 
process data in heterogenous distributed environment. 

The important point is that Web Services is used for messaging, data 
processing and data exchanging in heterogenous distributed environment. 
That's why we need to make the applicable Web Services area which are 
affected by Language/Locale negotiation clear.

* * * * * 

2. Locale data differences by platforms

Problem description: There is locale implementation differences usually. 
For example, the following is the current date formatting result of ja_JP 
locale. 

Java: 2003/01/15
Linux: 2003年01月14日
Windows: 2003/01/15

The following examples are usual locale sensitive messages using locale 
sensitive format.

Message examples
a) English "Invest $100,000 on 1/15/2003"
b) Japanese(Java ja_JP locale) "2003/01/15に￥100,000投資せよ" = "Invest 
￥100,000 on 2003/01/15"
c) Japanese(Linux ja_JP locale) "2003年01月15日に￥100,000投資せよ" = 
"Invest ￥100,000 on 2003nen01gatsu14ka"

My view: If the locale/i18n context is used for simple user interface, the 
locale implementation differences is not so critical problem. User can 
adjust the differences. 

However, 
1) In heterogenous environment, both message b) and c) can be displayed on 
the same interface, because Web Services can aggregate both messages using 
an user interface aggregation scenario. The data format differences is 
unsightly. 

2) If locale/i18n context is used for data processing, the locale 
implementation differences become problem because the result is varied by 
locale implementation environment. For example, if a requester requests a 
string comparison in ja_JP locale, the result of Java based Web services 
is not the same as the result of Linux based Web Services. 

Needs a mechanism to keep i18n consistency for service results. 

* * * * *

3. Locale Identifier

Problem: Locale naming rule is various. In homogeneous environment, locale 
name is equal to locale identifier. However, heterogenous environment such 
as Web Services, locale name is not equal to Locale identifier because 
naming rule is differed by Web Services runtime environment. 

My View: Needs an interoperable locale identification framework to 
identify any locales in Web Services. 

* * * * *

4. Categories of locale

Problem: Locale categories are varied by requester/provider's runtime 
environment. 

Linux/POSIX/XPG: Collation, Character Classification, Datetime format, 
Numeric format, Currency format, YesNo Response format, Code set. 
Java: ISO 3 lang, ISO 3 country, Languages, Countries, Collation, Datetime 
format, Numeric/Percent/Currency format. 
Windows XP NLS info: LCID, Locale name, Language, Code page, Number 
format, Currency format, Datetime format, Calendar.

Among above environment, interoperable common locale categories are 
Datetime/Numeric/Currency data format only. Needs an interoperable locale 
related categories/functions for heterogeneous Web Services operating 
environment. 

* * * * *

Kentaroh Noji

Received on Tuesday, 21 January 2003 03:17:44 UTC