[Comment on WS-I18N WD]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[Comment on WS-I18N WD]

Dan Chiba

Hello,

The WS-I18N draft specifically defines locale and timezone as element
information items.
http://www.w3.org/TR/2008/WD-ws-i18n-20080415/#sec-i18n

Is it possible to consider defining several other commonly used elements
as well?

Here is a list of items that we think are common:

  1. Locale (already defined)
  2. Timezone (already defined)
  3. Language (used when UI language is different from the language
deduced from the UI locale. e.g. "de" for German language, "fr-CH" for
Switzerland/French locale)
  4. Collation (based on the IANA collation registry)
  5. Charset (based on the IANA character set registry; for limited use,
generally discouraged)
  6. Date/Time Formats (based on LDML syntax)
  7. Number Format (based on LDML syntax)
  8. Currency Format (based on LDML syntax)
  9. Calendar (based on LDML calendar type?)

WS-I18N's defining more elements would enhance interoperability
significantly. For example, they could include the followings, then it
would be easier to coordinate the services and produce the desired
application behavior.

i18n:international/i18n:language?
i18n:international/i18n:preferences/iana:collation?
i18n:international/i18n:preferences/iana:charset?
i18n:international/i18n:preferences/ldml:dateFormat[@type="short"]?
<snip/>

It would be desirable for service implementors to use standard items so
that the implementations will be compatible with others.

Regards,
-Dan Chiba
Oracle Globalization Technology

Reply | Threaded
Open this post in threaded view
|

Re: [Comment on WS-I18N WD]

Dan Chiba

Based on the recent discussions, I revised the proposed specific i18n
items for explicit inclusion as follows:

  1. Locale (BCP 47 | "$neutral" | "$default")
  2. Timezone (Olson ID or RFC 822 zone offset)
  3. Language (identifies translation language, BCP 47)
  4. Collation (based on the IANA collation registry)
  5. Date/Time Formats (based on LDML syntax)
  6. Number Format (based on LDML syntax)
  7. Currency Format (based on LDML syntax)
  8. Calendar (based on LDML calendar type?)

Changes are:
* Locale identifier expects BCP 47 (delimiter is dash; no underscore).
* Language is moved down to become a child of i18n:preferences. (only
locale and tz are immediately under i18n:international)
* Charset is removed.

Clarifications:
* 3 - 8 are all optional.
* Language element may be used when it is desirable to honor user's
locale and language preferences independently.
* The language element is at
i18n:international/i18n:preferences/i18n:language. BCP 47 defines valid
values.
* The collation element is at
i18n:international/i18n:preferences/iana:collation. Collation Registry
defines valid values.
* The namespace for the collation element needs to be defined. (prefix
and the URI)

Is this a reasonable list of the element items now?

Regards,
-Dan

Dan Chiba wrote:

>
> Hello,
>
> The WS-I18N draft specifically defines locale and timezone as element
> information items.
> http://www.w3.org/TR/2008/WD-ws-i18n-20080415/#sec-i18n
>
> Is it possible to consider defining several other commonly used
> elements as well?
>
> Here is a list of items that we think are common:
>
>  1. Locale (already defined)
>  2. Timezone (already defined)
>  3. Language (used when UI language is different from the language
> deduced from the UI locale. e.g. "de" for German language, "fr-CH" for
> Switzerland/French locale)
>  4. Collation (based on the IANA collation registry)
>  5. Charset (based on the IANA character set registry; for limited
> use, generally discouraged)
>  6. Date/Time Formats (based on LDML syntax)
>  7. Number Format (based on LDML syntax)
>  8. Currency Format (based on LDML syntax)
>  9. Calendar (based on LDML calendar type?)
>
> WS-I18N's defining more elements would enhance interoperability
> significantly. For example, they could include the followings, then it
> would be easier to coordinate the services and produce the desired
> application behavior.
>
> i18n:international/i18n:language?
> i18n:international/i18n:preferences/iana:collation?
> i18n:international/i18n:preferences/iana:charset?
> i18n:international/i18n:preferences/ldml:dateFormat[@type="short"]?
> <snip/>
>
> It would be desirable for service implementors to use standard items
> so that the implementations will be compatible with others.
>
> Regards,
> -Dan Chiba
> Oracle Globalization Technology
>


Reply | Threaded
Open this post in threaded view
|

Re: [Comment on WS-I18N WD]

Frank Ellermann

Dan Chiba wrote:

>   2. Timezone (Olson ID or RFC 822 zone offset)
[...]
> Is this a reasonable list of the element items now?

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

OTOH that is unfair, RFC 822 can do any offset down
to minutes.  But this was later improved in 2822upd
(soon to be approved) among others:

| zone  =  (FWS ( "+" / "-" ) 4DIGIT) / obs-zone

That is far better, the cruft is in <obs-zone>, and
you could import 2822upd <zone> excl. <obs-zone>.

The prose is also better, e.g., it specifies -0000,
and it notes that the last two digits are limited
to 00..59, for the details compare

http://tools.ietf.org/html/draft-resnick-2822upd-06#section-3.3

There is also RFC 3339 specifying the "Internet
Date/Time format" (a no-nonsense subset or "profile"
of ISO 8601:2000).  RFC 3339 specifies:

| time-hour       = 2DIGIT  ; 00-23
| time-minute     = 2DIGIT  ; 00-59
[...]
| time-numoffset  = ("+" / "-") time-hour ":" time-minute
| time-offset     = "Z" / time-numoffset

You would not want the colon, because RFC (2)822(upd)
doesn't have it, but you might want the "Z", a part of
<obs-zone> in 2822upd.  Odd, the IETF USEFOR WG ended
up with adopting a 2822 <zone> excl. <obs-zone>, but
keeping one obsolete identifier, in that case it was
"UT", not "Z" (meaning the same thing, UTC).  The
"UT" was for NetNews backward compatibility, nothing
you need to worry about.

 Frank


Reply | Threaded
Open this post in threaded view
|

Re: [Comment on WS-I18N WD]

Felix Sasaki
In reply to this post by Dan Chiba

Hi Dan,

Dan Chiba さんは書きました:

>
> Based on the recent discussions, I revised the proposed specific i18n
> items for explicit inclusion as follows:
>
> 1. Locale (BCP 47 | "$neutral" | "$default")
> 2. Timezone (Olson ID or RFC 822 zone offset)
> 3. Language (identifies translation language, BCP 47)
> 4. Collation (based on the IANA collation registry)
> 5. Date/Time Formats (based on LDML syntax)
> 6. Number Format (based on LDML syntax)
> 7. Currency Format (based on LDML syntax)
> 8. Calendar (based on LDML calendar type?)
>
> Changes are:
> * Locale identifier expects BCP 47 (delimiter is dash; no underscore).
> * Language is moved down to become a child of i18n:preferences. (only
> locale and tz are immediately under i18n:international)
> * Charset is removed.
>
> Clarifications:
> * 3 - 8 are all optional.
> * Language element may be used when it is desirable to honor user's
> locale and language preferences independently.
> * The language element is at
> i18n:international/i18n:preferences/i18n:language. BCP 47 defines
> valid values.
> * The collation element is at
> i18n:international/i18n:preferences/iana:collation. Collation Registry
> defines valid values.
> * The namespace for the collation element needs to be defined. (prefix
> and the URI)
>
> Is this a reasonable list of the element items now?

it looks reasonable to me and I'm fine with editing the draft
accordingly . Of course there will be other more comments like the one
from Frank in this thread, but we have enough material to change the
draft. I will also change the schema at
http://www.w3.org/TR/ws-i18n/ws-i18n.xsd
I'll come back to this thread after both is done.

Felix

>
> Regards,
> -Dan
>
> Dan Chiba wrote:
>>
>> Hello,
>>
>> The WS-I18N draft specifically defines locale and timezone as element
>> information items.
>> http://www.w3.org/TR/2008/WD-ws-i18n-20080415/#sec-i18n
>>
>> Is it possible to consider defining several other commonly used
>> elements as well?
>>
>> Here is a list of items that we think are common:
>>
>> 1. Locale (already defined)
>> 2. Timezone (already defined)
>> 3. Language (used when UI language is different from the language
>> deduced from the UI locale. e.g. "de" for German language, "fr-CH"
>> for Switzerland/French locale)
>> 4. Collation (based on the IANA collation registry)
>> 5. Charset (based on the IANA character set registry; for limited
>> use, generally discouraged)
>> 6. Date/Time Formats (based on LDML syntax)
>> 7. Number Format (based on LDML syntax)
>> 8. Currency Format (based on LDML syntax)
>> 9. Calendar (based on LDML calendar type?)
>>
>> WS-I18N's defining more elements would enhance interoperability
>> significantly. For example, they could include the followings, then
>> it would be easier to coordinate the services and produce the desired
>> application behavior.
>>
>> i18n:international/i18n:language?
>> i18n:international/i18n:preferences/iana:collation?
>> i18n:international/i18n:preferences/iana:charset?
>> i18n:international/i18n:preferences/ldml:dateFormat[@type="short"]?
>> <snip/>
>>
>> It would be desirable for service implementors to use standard items
>> so that the implementations will be compatible with others.
>>
>> Regards,
>> -Dan Chiba
>> Oracle Globalization Technology
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [Comment on WS-I18N WD]

Dan Chiba
In reply to this post by Frank Ellermann

Hi Frank,

Frank Ellermann wrote:

> Dan Chiba wrote:
>
>  
>>   2. Timezone (Olson ID or RFC 822 zone offset)
>>    
> [...]
>  
>> Is this a reasonable list of the element items now?
>>    
>
> 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).

> OTOH that is unfair, RFC 822 can do any offset down
> to minutes.  But this was later improved in 2822upd
> (soon to be approved) among others:
>
> | zone  =  (FWS ( "+" / "-" ) 4DIGIT) / obs-zone
>
> That is far better, the cruft is in <obs-zone>, and
> you could import 2822upd <zone> excl. <obs-zone>.
>
> The prose is also better, e.g., it specifies -0000,
> and it notes that the last two digits are limited
> to 00..59, for the details compare
>
> http://tools.ietf.org/html/draft-resnick-2822upd-06#section-3.3
>
> There is also RFC 3339 specifying the "Internet
> Date/Time format" (a no-nonsense subset or "profile"
> of ISO 8601:2000).  RFC 3339 specifies:
>
> | time-hour       = 2DIGIT  ; 00-23
> | time-minute     = 2DIGIT  ; 00-59
> [...]
> | time-numoffset  = ("+" / "-") time-hour ":" time-minute
> | time-offset     = "Z" / time-numoffset
>
> You would not want the colon, because RFC (2)822(upd)
> doesn't have it, but you might want the "Z", a part of
> <obs-zone> in 2822upd.  Odd, the IETF USEFOR WG ended
> up with adopting a 2822 <zone> excl. <obs-zone>, but
> keeping one obsolete identifier, in that case it was
> "UT", not "Z" (meaning the same thing, UTC).  The
> "UT" was for NetNews backward compatibility, nothing
> you need to worry about.
>  
I quite agree with the idea to exclude <obs-zone>. Allowing "Z" would be
also good, because normalizing datetime values to UTC is very often a
good idea.

Regards,
-Dan
>  Frank
>
>
>  


Reply | Threaded
Open this post in threaded view
|

RE: [Comment on WS-I18N WD]

Phillips, Addison
> >>
> >
> > 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 agree with Frank that the references we used originally are stale.


> >
> Allowing "Z" would be
> also good, because normalizing datetime values to UTC is very often
> a good idea.

+1


Addison

[1] http://www.w3.org/TR/2005/NOTE-timezone-20051013/
Reply | Threaded
Open this post in threaded view
|

Re: [Comment on WS-I18N WD]

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, because normalizing datetime values to UTC is very often
>> a good idea.
>>    
>
> +1
>
>
> Addison
>
> [1] http://www.w3.org/TR/2005/NOTE-timezone-20051013/
>  


Reply | Threaded
Open this post in threaded view
|

Re: [Comment on WS-I18N WD]

Felix Sasaki

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
http://www.w3.org/TR/ws-i18n/ws-i18n.xsd
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?

Felix

Reply | Threaded
Open this post in threaded view
|

Re: [Comment on WS-I18N WD]

Dan Chiba

Felix Sasaki wrote:

> 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
> http://www.w3.org/TR/ws-i18n/ws-i18n.xsd
> 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?
>
> Felix
My opinion is that the schema should be slightly more specific; #3
language and #4 collation are not based on LDML so there should be
corresponding element definitions.
<xs:element name="language" type="xs:NMTOKEN"/>
<xs:element name="collation" type="xs:NMTOKEN"/>
All others are LDML based, so I think think they should be left to LDML.

Regards,
-Dan





Reply | Threaded
Open this post in threaded view
|

Re: [Comment on WS-I18N WD]

Dan Chiba
Please find attached a proposed draft update of Section 3.4, Providing
Locale Preferences, based on the discussions in the past few weeks.

Regards,
-Dan

Dan Chiba wrote:

> Felix Sasaki wrote:
>> 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
>> http://www.w3.org/TR/ws-i18n/ws-i18n.xsd
>> 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?
>>
>> Felix
> My opinion is that the schema should be slightly more specific; #3
> language and #4 collation are not based on LDML so there should be
> corresponding element definitions.
> <xs:element name="language" type="xs:NMTOKEN"/>
> <xs:element name="collation" type="xs:NMTOKEN"/>
> All others are LDML based, so I think think they should be left to LDML.
>
> Regards,
> -Dan
>
>
>
>
>

Web Services Internationalization (WS-I18N)

W3C


3.4 Providing Locale Preferences

The optional i18n:preferences element information item MUST appear at most one time in the children property of the i18n:international element information item. If present, it MUST follow the i18n:tz element information item or (if i18n:tz is omitted) the i18n:locale element information item.

The i18n:preferences element information item represents a way to construct specific locale preferences and overrides. Support for the <i18n:preferences> element is OPTIONAL and specific behavior in relation to any particular preference is implementation dependent. Implementations of this specification are not required to recognize, support, or acknowledge the i18n:preferences element information item or any of its sub-elements. Services MUST NOT require a i18n:preferences element information item be sent in order to operate correctly.

[DC begins]

3.4.1 Providing Language Information

The optional i18n:language element information item MAY appear at most one time in the children property of the i18n:preferences element information item.

The i18n:language element information item represents the natural language of the web services interaction. Its value MUST be a valid [BCP 47] language tag.

An example of the usage of i18n:language is given below.

In this example, the i18n:language element information item is used to override the natural language to French (fr). The German locale (de-DE) is used for the rest of the locale sensitive service operations such as data formatting.

(01) <i18n:international>
(02) <i18n:locale>de-DE</i18n:locale>
(03) <i18n:preferences>
(04) <i18n:language>fr</i18n:language>
(05) </i18n:preferences>
(06) </i18n:international>


3.4.2 Providing Collation Information

The optional i18n:collation element information item MAY appear at most one time in the children property of the i18n:preferences element information item.

The i18n:collation element information item represents the collation used in the web services operation. Its value MUST be a valid [IANA] collation identifier.

An example of the usage of i18n:collation is given below.

In this example, the i18n:collation element information item is used to convey the usage of the "i;ascii-casemap" collation, which operates on US-ASCII letters in a case-insensitive manner.

(01) <i18n:international>
(02) <i18n:locale>en-US</i18n:locale>
(03) <i18n:preferences>
(04) <i18n:collation>i;ascii-casemap</i18n:collation>
(05) </i18n:preferences>
(06) </i18n:international>


3.4.3 Providing Date Time Format Information

The optional date time format information items MAY appear in the children property of the i18n:preferences element information item. They are indicated using the calendar elements of [LDML].

(01) <ldml:calendar type=" calendar type based on [LDML] ">
(02) <ldml:dateFormats>
(03) <ldml:dateFormatLength type=" date format length based on [LDML] ">
(04) <ldml:dateFormat>
(05) <ldml:pattern> date format pattern based on [LDML] </ldml:pattern>
(06) </ldml:dateFormat>
(07) </ldml:dateFormatLength>
(08) <ldml:dateFormats>
(09) <ldml:timeFormats>
(10) <ldml:timeFormatLength type=" time format length based on [LDML] ">
(11) <ldml:timeFormat>
(12) <ldml:pattern> time format pattern based on [LDML] </ldml:pattern>
(13) </ldml:timeFormat>
(14) </ldml:timeFormatLength>
(15) <ldml:timeFormats>
(16) <ldml:dateTimeFormats>
(17) <ldml:dateTimeFormatLength type=" date time format length based on [LDML] ">
(18) <ldml:dateTimeFormat>
(19) <ldml:pattern> date time format pattern based on [LDML] </ldml:pattern>
(20) </ldml:dateTimeFormat>
(21) </ldml:dateTimeFormatLength>
(22) <ldml:dateTimeFormats>
(23) </i18n:calendar>

The ldml:calender element information item represents specific date time format(s) used in the web services operation. The ldml:calender element and any child date time format element MAY appear multiple times if their combination of the type attributes are different from each other. All values under the ldml:calender element MUST conform to [LDML].

Gregorian calendar is the default calendar system. That is, the ldml:calender element MAY be omitted, in which case the elements ldml:dateFormatLength, ldml:timeFormatLength and ldml:dateTimeFormatLength MAY appear as an immediate child of the i18n:preferences element.

An example of the usage of date time format information is given below.

In this example, the ldml:pattern element represents a specific date format of medium length for the gregorian calendar.

(01) <i18n:international>
(02) <i18n:locale>en-US</i18n:locale>
(03) <i18n:preferences>
(04) <ldml:dateFormatLength type="medium">
(05) <ldml:dateFormat>
(06) <ldml:pattern>MMM dd, yyyy</ldml:pattern>
(07) </ldml:dateFormat>
(08) </ldml:dateFormatLength>
(09) </i18n:preferences>
(10) </i18n:international>

3.4.4 Providing Number Format Information

The optional number format information items MAY appear in the children property of the i18n:preferences element information item. They are indicated using the number elements of [LDML].

(01) <ldml:numbers>
(02) <ldml:decimalFormats>
(03) <ldml:decimalFormatLength type=" decimal format length based on [LDML] ">
(04) <ldml:decimalFormat>
(05) <ldml:pattern> decimal format pattern based on [LDML] </ldml:pattern>
(06) </ldml:decimalFormat>
(07) </ldml:decimalFormatLength>
(08) <ldml:decimalFormats>
(09) <ldml:scientificFormats>
(10) <ldml:scientificFormatLength type=" scientific format length based on [LDML] ">
(11) <ldml:scientificFormat>
(12) <ldml:pattern> scientific format pattern based on [LDML] </ldml:pattern>
(13) </ldml:scientificFormat>
(14) </ldml:scientificFormatLength>
(15) <ldml:scientificFormats>
(16) <ldml:percentFormats>
(17) <ldml:percentFormatLength type=" percent format length based on [LDML] ">
(18) <ldml:percentFormat>
(19) <ldml:pattern> percent format pattern based on [LDML] </ldml:pattern>
(20) </ldml:percentFormat>
(21) </ldml:percentFormatLength>
(22) <ldml:percentFormats>
(23) <ldml:currencyFormats>
(24) <ldml:currencyFormatLength type=" currency format length based on [LDML] ">
(25) <ldml:currencyFormat>
(26) <ldml:pattern> currency format pattern based on [LDML] </ldml:pattern>
(27) </ldml:currencyFormat>
(28) </ldml:currencyFormatLength>
(29) <ldml:currencyFormats>
(30) </ldml:numbers>

The ldml:numbers element information item represents specific number format(s) used in the web services operation.  All values under the ldml:numbers element MUST conform to [LDML].

An example of the usage of number format information is given below.

In this example, the ldml:pattern element represents a specific long decimal format.

(01) <i18n:international>
(02) <i18n:locale>en-US</i18n:locale>
(03) <i18n:preferences>
(04) <ldml:numbers>
(05) <ldml:decimalFormats>
(06) <ldml:decimalFormatLength type="long">
(07) <ldml:decimalFormat>
(08) <ldml:pattern>,##0.###</ldml:pattern>
(09) </ldml:decimalFormat>
(10) </ldml:decimalFormatLength>
(05) </ldml:decimalFormats>
(04) </ldml:numbers>
(11) </i18n:preferences>
(12) </i18n:international>


3.4.5 Providing Currency Information

The optional currency element information item MAY appear in the children property of the i18n:preferences element information item. They are indicated using the number elements of [LDML].

(01) <ldml:currency type=" currency type based on [LDML] " />

The currency element information item represents the currency used in the web services operation. Its value MUST be a valid [LDML] currency type.

An example of the usage of i18n:collation is given below.

In this example, the ldml:currency element information item is used to express the preferred currency (US dollar) on a request or the currency used on the service response.

(01) <i18n:international>
(02) <i18n:locale>en-US</i18n:locale>
(03) <i18n:preferences>
(04) <ldml:currency type="USD" />
(05) </i18n:preferences>
(06) </i18n:international>

3.4.6 Using The Extension Point

The i18n:preferences element information item may contain other items that are not defined in this specification.

[DC end]

An example of the usage of i18n:preferences is given below. It describes preferences using [LDML].

In this example, the i18n:preferences element information item used to convey the usage of a specific metric system.

(01) <i18n:preferences>
(02) <ldml:measurementSystem type="metric" />
(03) </i18n:preferences>

The LDML alias element information item is demonstrated below as another example of the content of the i18n:preferences element information item. alias allows the application to specify a base locale or collection of data from the Common Locale Data Repository [CLDR] to serve as a basis for other preferences. Thus it can be used to import a large number of settings that the remaining preferences tailor.

If the following i18n header is received and the specific preferences requested are supported, then the service should be expected to obey the locale request of U.S. English ("en-US"), but uses the German ("de_DE") collation specified ("phonebook" in this case).

(01) <i18n:international>
(02) <i18n:locale>en_US</i18n:locale>
(03) <i18n:preferences>
(04) <ldml:collation>
(05) <ldml:alias source="de_DE" type="phonebook"/>
(06) </ldml:collation>
(07) </i18n:preferences>
(08) </i18n:international>