[threeten-dev] CLDR Islamic calendar subtag updates

[yoshito_umaoka at us.ibm.com]

> Thank you for the update, it is timely since we will need to stabilize 
> the behavior
> of the JDK shortly.  I would agree that a single string is more 
> convenient for implementations.

Great.

> 
> With reference to the document:
> http://cldr.unicode.org/development/development-process/design-
> proposals/islamic-calendar-types
> 
> 1. In the table: "Proposed Calendar Type Value Changes"
>      Should there be a row for "islamic-umalqura"? It appears in the xml 

> form but not the table.

Sorry. I forgot to add the row - I updated the table and added 
islamic-umalqura.

> 
> 2. With respect to the simple subtag "islamic",  is an implementation 
free
>       to choose a consistent but arbitrary calendar to identify as 
"islamic"
>       or is it expected that the simple string is not a sufficient 
> identifier and is an error?
>       (JSR 310 would default to "islamic-umalqura")

My intention is the former.

"islamic" alone may be used when algorithm variations are not important.
A consumer of LDML may use a specific Islamic algorithm variant as the 
default.

This approach would work better if someone wants to add a new variation to 
the existing calendar type.

For example, JDK's Japanese calendar uses Gregorian but just altering 
eras. If someone want to provide more accurate implementation (using 
Japanese variation of Chinese lunisolar calendar before 1873), then it 
might be identified as "japanese-historic" or something.

> 
> 3. In Hierarchical Calendar Type Subtags:
>      There is mention of a prefix match;  I would assume it only applies
>      to matching of complete subtags, not prefixes of arbitrary lengths.

Yes - it should only applies to matching of complete subtags.

>      Also the matching only applies to the lookup of formatting data
>      from the calendar type, not of the calendar itself.

I think it really depends on use cases.
The LDML specification would just explain that the first subtag specifies 
arbitrary calendar type and the rest specifies an algorithm variant. Of 
course, it is intended for supporting such fallback algorithm. But how to 
handle prefix match is really up to the consumer's decision.

For future backward compatibility support purpose, I guess JSR310 may also 
apply the prefix match fallback - If this is well-documented and there is 
a way to know the exact type resolved for a given type, then I don't see 
any major issues there.

> 
> 4. Is/will the type-subtype syntax be rigorously consistent with BCP47?
> 

For calendar type - that's the plan - and I'd like to clearly specify the 
policy in the LDML specification.
For other types (like collation, number... etc) - No.


> Do you have an expectation about when v24 will be finalized?

CLDR 24 release is currently planned on Sep 18, 2013.

I'll try to finish all of changes for this specific item much earlier 
(including spec update review).


-Yoshito