Re: FW: [Distributed services] What is i18n on web services based webapplications

Addison,
A few imbedded comments:

"Addison Phillips [wM] (by way of Martin Duerst )" wrote:
> 
> 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 ......]

Almost all apps need an i18n architecture :-)

> 
> 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 think this is a good idea.

> 
> 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.).

But we all know it doesn't (I assume that's what you're implying here).

> 
> 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).

It's that "nearly" which will bite us.

> 
> 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...

Where possible, of course.  The client can request anything, but it's the server
which must decide what it can and should serve.

Of course the above is language-based, not (usually) locale-based.

> 
> 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"?)

Prefer not.  This is an opportunity to separate language and locale.  Please
let's take advantage of it, and maybe other protocols and apps will follow.  I'm
not saying you can't have a language fr-CA, what I'm saying is you can have a
locale US (or en_US just to keep the current naming convention) and have a
language of fr-CA.  Servers now may not be able to accommodate fr-CA, but little
by little they will *if* we provide the mechanism.  No mechanism, no chance for
provision.

> 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.

If, as you say below, xml:lang is to be regarded strictly as an attribute (which
I think is a good idea), then so goes xml:locale.  I believe requests for a
language and for a locale require a separate *tag*, not an attribute. 
Accept-language is separated from Content-language.  What we want and what we
get are 2 different 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.

OK, you're crazy (happy to oblige).  But if that is true, then many of us are.

I don't see the relevance of hops.  A client requests a locale - the request. 
Regardless of the number of hops, doesn't the request remain the same?  
The server serves a locale - the content locale.  Again, why should hops change
this?  Are you suggesting that there are other services which will take the data
and format it according to the locale, without a separate SOAP envelope with a
separate request-locale and content-locale?  Or am I missing something?

> 
> 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?).

I vote for a tag.  Its use can be optional, but when it is used, it should
always be via that particular tag and its attributes.

> 
> 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??)

Yes, absolutely.

> 
> 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.

Agree.  Start with what we know and have, work up to what would be helpful in
the future.  The advantage of a separate locale tag is that attributes can be
added later on, but the tag remains stable.

Andrea Vine
iPlanet i18n architect

Received on Monday, 8 April 2002 14:38:55 UTC