On 7/13/2013 8:48 PM, Andy Earnshaw wrote:
> On Sat, Jul 13, 2013 at 1:05 PM, André Bargull <andre.bargull at udo.edu
> <mailto:andre.bargull at udo.edu>> wrote:
>
>     ...
>     Only exposing CanonicalizeLanguageTag does not seem useful to me
>     without having access to IsStructurallyValidLanguageTag. Most likely
>     a combined IsStructurallyValidLanguageTag + CanonicalizeLanguageTag
>     function is necessary/wanted for most use cases.
>
>
> Hmm.  I'm not sure I'd agree it's necessary.
>   IsStructurallyValidLanguageTag makes sense as an abstract function
> because you need to throw accordingly when an invalid tag is passed to
> the constructors or methods.  However, it's still the developer's
> responsibility to make sure their tags are valid during the development
> process.  Canonicalisation would still throw an error if the tag is invalid.

CanonicalizeLanguageTag isn't even defined for non-structurally valid 
language tags. That's why I meant a combined 
IsStructurallyValidLanguageTag + CanonicalizeLanguageTag function is 
more useful than access to the bare CanonicalizeLanguageTag function.


>
>     I don't see why you'd need to change CanonicalizeLocaleList at all.
>     Just let it return the internal list as-is, and then define
>     `Intl.canonicalizeLocaleList` like so:
>
>
> Lists are internal, they aren't part of the ECMAScript language.  It
> makes no sense to return an internal list to ECMAScript code unless you
> intend to go the whole hog and specify them with a constructor/prototype.

The internal list structure is not returned to user code instead a 
possible `Intl.canonicalizeLocaleList` function is a simple wrapper 
around CanonicalizeLocaleList to perform the necessary conversion from 
list to array. That's exactly the point of the algorithm steps in my 
previous mail.


>
>     It also needs to be considered whether the duplicate removal in
>     CanonicalizeLocaleList creates any issues for users of a potential
>     `Intl.canonicalizeLocaleList` or `Intl.canonicalizeTags` function.
>
>
> Perhaps.  Are there any cases you think of where removing duplicates
> would be a problem?

I thought about use cases when a user assumes the i-th element of the 
output array is the canonicalised value of the i-th element in the input 
array. I can't tell whether this is a valid use case - I've only 
implemented ECMA-402, so I know a bit about the spec, but never actually 
used it in an application...


>
> Andy


- André

On 7/13/2013 8:48 PM, Andy Earnshaw wrote:
> On Sat, Jul 13, 2013 at 1:05 PM, André Bargull <andre.bargull at udo.edu> wrote:
>
>> ...
>> Only exposing CanonicalizeLanguageTag does not seem useful to me
>> without having access to IsStructurallyValidLanguageTag. Most likely
>> a combined IsStructurallyValidLanguageTag + CanonicalizeLanguageTag
>> function is necessary/wanted for most use cases.
>
>
> Hmm.  I'm not sure I'd agree it's necessary.
>   IsStructurallyValidLanguageTag makes sense as an abstract function
> because you need to throw accordingly when an invalid tag is passed to
> the constructors or methods.  However, it's still the developer's
> responsibility to make sure their tags are valid during the development
> process.  Canonicalisation would still throw an error if the tag is invalid.

CanonicalizeLanguageTag isn't even defined for non-structurally valid 
language tags. That's why I meant a combined 
IsStructurallyValidLanguageTag + CanonicalizeLanguageTag function is 
more useful than access to the bare CanonicalizeLanguageTag function.


>> I don't see why you'd need to change CanonicalizeLocaleList at all.
>> Just let it return the internal list as-is, and then define
>> `Intl.canonicalizeLocaleList` like so:
>
> Lists are internal, they aren't part of the ECMAScript language.  It
> makes no sense to return an internal list to ECMAScript code unless you
> intend to go the whole hog and specify them with a constructor/prototype.

The internal list structure is not returned to user code instead a 
possible `Intl.canonicalizeLocaleList` function is a simple wrapper 
around CanonicalizeLocaleList to perform the necessary conversion from 
list to array. That's exactly the point of the algorithm steps in my 
previous mail.


>> It also needs to be considered whether the duplicate removal in
>> CanonicalizeLocaleList creates any issues for users of a potential
>> `Intl.canonicalizeLocaleList` or `Intl.canonicalizeTags` function.
>
> Perhaps.  Are there any cases you think of where removing duplicates
> would be a problem?

I thought about use cases when a user assumes the i-th element of the 
output array is the canonicalised value of the i-th element in the input 
array. I can't tell whether this is a valid use case - I've only 
implemented ECMA-402, so I know a bit about the spec, but never actually 
used it in an application...