- From: A. Vine <andrea.vine@sun.com>
- Date: Fri, 08 Mar 2002 10:54:14 -0800
- To: Martin Duerst <duerst@w3.org>
- CC: Jeremy Carroll <jjc@hplb.hpl.hp.com>, w3c-i18n-ig@w3.org, w3c-rdfcore-wg@w3.org
Martin, Martin Duerst wrote: > > At 10:08 02/03/07 -0800, A. Vine wrote: > >And to add to Misha's comment: > > > >There is no tag for locale. Anywhere. > > > >The reason often stated is that locale is a client concept, not a data > >concept. > >Of course, in the example below, it is a data concept. > > In the example of 1.234,56 appearing in text (e.g. HTML), we as humans > see it as data. It is locale-formatted data, which has nothing to do with the client it's on. > But for the computer, it's just part of a string. > Marking it up, e.g. with something like > <number value='1234.56'>1.234,56</number> > (not available in HTML) will identify it to the computer as data. Whether it has a value to the computer depends very much on the nature of the processing going on. You can call it a string, or you can call it text, or you can call it data. What it is _not_ is locale-neutral. It has a locale. The point being that this is an example where only having the locale info at the client is not sufficient. Even if you have a value parm in the tag, the data itself still has a locale - and you, the creator of the processing software, may very much want to know what that locale is. You might want to change the way it is displayed, or put a pop-up tag for a mouse-over to alert the user, or who knows what. There are times where the locale tag would be ignored, just as the lang tag is sometimes. I recognize that there are 2 aspects to locale-specific info, syntax and semantics. This could simply be syntactically locale-specific. The value parm would be useful for calculations and comparisons done on the actual value. > > This is similar to having "This document was authored by > Ora Lassila" in plain text; RDF doesn't automatically capture it, > it has to be transferred into RDF. Going up the semantic ladder > is difficult and requires work. > > >Another reason is that > >locales are not standardized - and this is actually a bigger problem. > > This has come up at the recent I18N Workshop > (http://www.w3.org/2002/02/01-i18n-workshop/). If you are interested > in further discussion on what W3C should do in this area, please > subscribe to www-i18n-workshop@w3.org (sending 'subscribe' in the > subject to www-i18n-workshop-request@w3.org). > See also the announcement e.g. at > http://lists.w3.org/Archives/Public/www-international/2002JanMar/0088.html. I assume this message is for other people on the list - as you know I'm already subscribed. > > >In order to determine equivalency between 2 different locale-based formats, > >standard internal representations would have to be agreed upon, which are not > >necessarily US format. In fact, most internal representations of numeric > >values > >are usually more cryptic than a locale-based format, for efficiency. > > The W3C has a collection of standard formats for data exchange, defined > in XML Schema Part 2: Datatypes (http://www.w3.org/TR/xmlschema-2/). > Some of these are close to US formats, but some of them are quite different, > but all of them are textual. Right, I'll make sure to document this info for my groups here, thanks. Andrea
Received on Friday, 8 March 2002 13:51:47 UTC