RE: [Distributed services] Locale Data Repository and associated web services

Eric,

That's what I just said, only different, I think.

If I request that you format my data or process my request using locale
"en-US", this presupposes that:

a) you have a locale called "en-US" (or can map "en-US" to something
suitable). Generally it's the latter. For example, in Java you would
probably use new Locale("en","US").

b) that the locale you call "en-US" is at least similar to the one I call
"en-US". That is, I can process the response I get from you using the locale
settings requested and not experience things like parsing errors introduced
by the application of the locale.

NB> Of course, one wants to avoid passing locale-neutral data in a locale
affected format in the first place, but I digress.

There is, as you say, a lot more than a universal namespace to chew on. In
fact, I think you are misinterpreting my proposal, which was to NOT to
define a univeral set of locale characteristics, ONLY the locale and
language tags, thus avoiding the problem. I have argued long and hard over
on the locales list AGAINST building a huge new incompatible locale model.
My argument is: if you just give me the locale tag and I make sense of it,
you have to trust that I'm doing the right thing. Generally the application
knows more about its business than the caller does anyway.

The only thing I saw this morning in Tom's proposal was: what if I don't
have "xx-YY"? Well, now I could look up "xx-YY" locale data and use it to
respond appropriately. But I separate that utterly from the negotiation
scheme, which I want to be simple and vendor neutral (and therefore only
include the attributes that are necessary--in my mind it would be limited to
just the locale tag itself).

IOW> I agree with you completely.

Thanks,

Addison

> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:brunner@nic-naa.net]
> Sent: Monday, April 15, 2002 10:30 AM
> To: Addison Phillips [wM]
> Cc: tom garland; www-i18n-workshop@w3.org; brunner@nic-naa.net
> Subject: Re: [Distributed services] Locale Data Repository and
> associated web services
>
>
> Addison,
>
> I'm sure there is more than just a consistent universal namespace to chew
> on. That particular bone has been gnawed on by lots of people who may be
> more interested in universally true stuff than in locally true stuff.
>
> When I read your proposal, I didn't notice that the request/response and
> negocation semantics would fail if every property failed to have global
> scope.
>
> Back when I worked for Unix vendors (xpg4.2, I consider it "standard"),
> even the file system namespace for locales was vendor-specific. I would
> not however infer from a lack of uniformity, file system syntax, or the
> semantics of the (xpg3) locale, or for that matter, the object file
> formats of semantically indistinguishable, possibly even syntactially
> indistinguishable locales, that this is a defect.
>
> This brings back locale internals, stuff I forgot I knew, as practiced
> at HP and SMI.
>
> So, I don't think my definition of X needs to agree with yours, except
> where we agree we care, which in general is application specific, and
> a proper subset of a (xpg3) POSIX locale, possibly extended.
>
> Eric
>

Received on Monday, 15 April 2002 14:03:00 UTC