RE: Editor's Draft, Use Case Document Posted

All:

This really is an excellent document. Thanks again Kentaroh for your valuable contribution.

My comments on this draft:

Section 2.2.2: We should note that xml:lang can also imply the language.

It should also be noted that human-readable messages (such as fault messages) often contain formatted substitution values ("On {0,date} at {1, time} there were {2,number,integer} errors.") that are locale affected. Neither xml:lang nor Accept-Language are entirely suitable for getting the formats of these values.

Section 2.4.2: This isn't actually locale sensitive data. The currency type is loosely linked to a locale in most cases (that is, the country in many locales implies a currency), but the relationship is locale->currency and it is 1:[0..n], not 1:1 or 1:n. That is, a locale may not imply ANY currency. In addition, a currency may not imply a locale either (the Euro and USD span several locales, and some currencies like BEF may imply more than one language and hence locale).

I guess what I'm saying is that if we're going to show "locale sensitive data", it should actually *take* a locale field and not some other value. I agree that 2.4.2 describes an internationalization problem. I'm just not sure it describes a locale problem. I think that there are very few examples of data structures that take a locale field (except for a locale, but that is solopsistic).

Also 2.4.2: Timezone requires more data in order to fully disambiguate. The GMT offset varies according to the daylight savings time rules (and thus the current date). It would be better to adopt the tz standard names as used by (for example) Java.

For similar comments, see: http://lists.w3.org/Archives/Public/www-p3p-public-comments/2000Feb/0009.html.

Section 2.5: I'm also not sure I agree with this concept. Sending picture strings is well-and-good if all clients are the same OS and programming language, but the semantics are bound to be difficult in this area. And it is more difficult to tell who's preferences should override the other. In Windows I can set quite detailed preferences for numeric display, for example. I would expect that a well-internationalized client might obey these settings to display XML data to me. Having the server create picture strings (for example) strikes me as quite problematic. This suggests that the server has to have specific client preferences, if I understand correctly.

Section 2.6.2: I agree that this kind of operation requires special handling. Locale negotiation is necessary to enable locale-sensitive data exchange. I'm not sure I agree that we should enable locale-sensitive data fields, though. XML Schema date/time formats, for example, are capable of exchanging the raw date value and the local system has more information about things like calendar preference.

The problem here, for example, is that some systems (notably Java) do not have standard mechanisms for everything. Calendars are a good example. Japanese calendar. Islamic calendar. Any non-Gregorian Calendar isn't supported by Java directly (without a special library like ICU). This means that Kentaroh's example is a valid one: Japanese users may wish to have the server create that Heisei date string.

Section 2.8 through 2.11. This describes various strategies for negotiating a locale between the sender and receiver.

As this email is getting long and I need to think about sections 2.8->2.11 carefully, I'll stop here.

Addison

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

+1 408.962.5487 (phone)  +1 408.210.3569 (mobile)
-------------------------------------------------
Internationalization is an architecture.
It is not a feature. 

Chair, W3C-I18N-WG Web Services Task Force
To participate see http://www.w3.org/International/ws

Received on Tuesday, 19 November 2002 16:30:57 UTC