W3C home > Mailing lists > Public > www-i18n-comments@w3.org > June 2008

Re: [Comment on WS-I18N WD]

From: Felix Sasaki <fsasaki@w3.org>
Date: Wed, 25 Jun 2008 08:25:06 +0900
Message-ID: <48618252.6030204@w3.org>
To: Dan Chiba <dan.chiba@oracle.com>
CC: "Phillips, Addison" <addison@amazon.com>, Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, "www-i18n-comments@w3.org" <www-i18n-comments@w3.org>

Dan Chiba さんは書きました:
> Phillips, Addison wrote:
>>>> I'm not sure about "RFC 822 zone offset", that is
>>>> for my European eyes rather US-centric, and not what
>>>> I'd expect in a memo claiming to be about I18N.  The
>>>> draft says:
>>>> | Note that RFC 822 zone offsets are not complete
>>>> | time zone identifiers
>>> Yes I think this is an important note. Zone offsets are not very
>>> useful
>>> because it does not identify a time zone. I think this note implies
>>> using Olson ID is preferred. (for this reason I intentionally put
>>> it
>>> first, switching from the order in the draft).
>> I think you draw too broad a conclusion here. I agree that zone 
>> offsets do not fully identify time zones [1]. However, you can't 
>> really say that "zone offsets are not very useful", because there are 
>> plenty of cases in which they are exceedingly useful, such as the 
>> many cases in which one only has an offset and not a full time zone. 
>> To deny a system that has only the offset the ability to specify it 
>> seems foolish, which is why I included that particular representation 
>> originally.
> I do think zone offsets are useful in some cases and should be valid. 
> I did not mean to deny a system that can only identify the offset. I 
> meant generally full time zone is preferred to offset alone. (However 
> in reality full time zone identification is often not achieved or 
> supported - web client, calendar, XML schema and ISO 8601, to name a 
> few.)
> Regards,
> -Dan
>> I agree with Frank that the references we used originally are stale.
>>> Allowing "Z" would be
>>> also good,

not directly a contribution to this thread, but a related question: what 
kind of specificity do you expect from the schema at
currently we have
<xs:element name="locale" type="xs:NMTOKEN"/>
<xs:element name="tz" type="xs:NMTOKEN"/>
and for i18n:preferences an element / attribute extensibility point. Is 
that enough and should we leave editors to themselves and / or to other 
specs, e.g. if they want to construct adequate date format 
specifications like the one's Dan mentioned?

Received on Tuesday, 24 June 2008 23:26:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:16 UTC