[loc-en-dev] getLocaleKeywordKeys/Value

[Yoshito Umaoka]

I agree with Doug.  I considered a generic type "Extension" and its 
subclass for "LDMLExtension" to represent the LDML extension while I was 
working on the early proto-type, but I soon realized that it require 
downcasting to access LDML keyword values.  I thought the API design 
requiring downcasting was not good.  I reconsidered the option and other 
potential implementations after the conf call, but I ended up the same 
conclusion with Doug.  I think even we design extension as a generic 
type, it does not mean that Java users can simply integrate their own 
handler for new extension types, unless we add SPI framework for this.  
At least for now, we do not see any use cases other than LDML's usage.  
So adding such framework looks over engineering.  As Doug pointed out, 
it also implies that Builder#setExtension needs to be extensible, but we 
do not want to break the assumption that Builder only creates 
well-formed Locales.  It's possible, but I do not see any good reasons 
to build complex framework for things which might be never used.  JDK 
itself is interested in LDML extensions and I think we do not have any 
objections that we're going to use LDML keywords to represent cultural 
behavior difference within a single base locale, rather than inventing 
more proprietary variants.  So I think LDML extension has special 
semantics for JDK.

I would like to wrap up this design strategy discussion by next week.  
If anyone disagree to this, please respond to this ML with actual 
counter API specification with a JavaDoc.

Thanks,
Yoshito

Doug Felt wrote:
> Yesterday during the conference call there was an objection raised to 
> providing LDML-extension-specific API on Locale.
>
> The argument against, as I understand it, is that in the future there 
> might be other extensions, and Locale might need to support them.  
> Special casing support for the LDML extension doesn't look clean.
>
> The argument for, as I understand it, is that LDML extensions are in 
> process and will be defined before JDK7 is released, and that these 
> are important for making use of LDML data in the JDK.
>
> One suggested compromise was to provide an LDML accessor object so 
> that the LDML-specific API resided on a different class.  I think this 
> is not going to work out.
>
> It seems to me that we would require an LDML-specific builder as well 
> as an accessor.  Locale.Builder currently understands both  BCP47 and 
> LDML syntax constraints, so knowledge of the LDML API and constraints 
> would have to be migrated off it.   An LDML builder that holds the 
> LDML-specific API is mutable, but ideally the LDML accessor is not (it 
> represents the LDML extension on a Locale in API form, and 
> semantically this is cleaner if it is also immutable, like Locale), so 
> this means two classes per extension, an accessor and a builder (just 
> like there is both a Locale and a Locale.Builder).
>
> Builder is currently strict, and I don't think we want to make it 
> strict only for BCP47 and non-strict for extensions.  So we'd need to 
> provide API on Builder that allows for imposition of those additional 
> extension constraints from outside.
>
> Builder currently provides a public setExtension(String) API.  Access 
> to this API without going through an extension builder means it is 
> possible to create language tags that are well-formed from the point 
> of view of BCP47 but that contain ill-formed LDML (or other extension) 
> tags.  Thus this API cannot take a String unless it already knows how 
> to syntax check the extension.  This API could be changed to take an 
> ExtensionBuilder instead of a String, but then the same problem occurs 
> with setLanguageTag.  Since this can take strings containing multiple 
> extensions we'd either need to parameterize the call with extension 
> builders or parameterize the Builder itself with extension syntax 
> checkers.
>
> A user-implementable API for extension builders means it is also 
> possible to create different builders for the same extension with 
> conflicting syntax constraints.
>
> So I think we'd probably want to implement extension support in the 
> JDK in a non-extensible way.  Once we do that, it's baked in anyway, 
> so the question is whether we put the API in Locale and 
> Locale.Builder, or on some other objects.  Putting it on other objects 
> makes use of the APIs much more cumbersome, especially as this is the 
> default use.  Putting the API on Locale and Locale.Builder doesn't 
> prelude adding other API in the future and makes the use of Locale and 
> the Builder significantly simpler.
>
> Doug
>