[threeten-dev] CLDR Islamic calendar types

[Dan Chiba]

Yoshito-san,

On 1/28/2013 9:40 AM, yoshito_umaoka at us.ibm.com wrote:
> > May I ask why there is a padding on "sa" for Saudi Arabia and it 
> becomes
> > "cv-sa0"?
>
> BCP47 u locale extensions reserve two letter subtag for keys (such as 
> ca for calendar, co for collation). Extension values (such as islamic, 
> gregory, ...) must be at least 3 characters, up to 8 characters (max 8 
> comes from the BCP 47 subtag syntax restriction).
>
Ok, I was only aware of BCP47:

  extension     = singleton 1*("-" (2*8alphanum))

Is it correct that the Unicode extension tightens this rule to 3 to 8 
letters (in RFC6067 section 2.1, first bullet)?
I fixed the 310 description to 3 to 8:
https://github.com/ThreeTen/threeten/issues/118#issuecomment-12301195
> I mentioned regional variant of non-algorithmic Islamic calendar might 
> be identified by country code based subtag, but I want to hold this 
> one for now, because of several reasons as I mentioned in the proposal 
> document - 1) country might not be right level of grouping 
The idea was not using an ISO country code as is, but using the BCP47 
region subtags; I totally agree with (3) below.

> 2) such syntax based value may explode possible subtag values 
> unnecessarily 
> 3) in most case, region subtag in BCP 47 may sufficient 
Yes, this is precisely the intent.
> 4) sighting based calendar might not be suited for open data interchange.
There should be no problem as far as the variant is unambiguously 
identified and its definition is properly managed. Our intent is 
enabling interchange of Islamic dates for major variants.
>
>
> I'm happy to collect review feedback on this point and make a final 
> decision in CLDR TC. Do you think such syntax is necessary?
Yes, I think this is helpful, although currently we only plan to support 
"sa0" for this kind.
>
>
> > I agree with Stephen that ideally each variant should have a full
> > specification. I wonder if LDML could simply say the cv value should be
> > one of the externally defined standard formal variant identifiers. And
> > then there could be a separate registry that assigns the formal ID and
> > specifies the variants or provides reference. I think this may take 
> some
> > time to establish and we can manually maintain the formal values for 
> the
> > time being.
> >
>
> The u locale extension is officially maintained by the CLDR project 
> and the set of available subtags are included in bcp47/*.xml in each 
> CLDR release. These XML files contains at least short description of 
> the meaning of each subtag.
>
> Like other type of BCP 47 subtags, the process is open for everyone. 
> And the CLDR project accepts reasonable requests in reasonable turn 
> around time, as I did this time. (Of course, some modifications might 
> be done based on some research and technical review.)
>
> In general, private extension can be included in BCP 47 x- subtag. The 
> u extension name space may also define a syntax for private extension 
> for a certain purpose, but I'm not sure it's really a good idea for 
> calendar (ca) and its variants (cv).
>
I think it is great if CLDR can define cv values in bcp47/*.xml. Would 
it be reasonable to have a longer description as well, so more 
information can be added? If this long description field can carry a 
reference to the full specification, no external registry would be 
necessary.

Regards,
-Dan
> -Yoshito