On Jul 13, 2013, at 12:37 , André Bargull <andre.bargull at udo.edu> wrote:

> 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.

Correct. As currently specified, the CanonicalizeLanguageTag abstract operation assumes that its input is a String value that's a structurally valid language tag. An API cannot make such assumptions - it has to be ready to deal with any input, as well as the absence of input. It has to do something like the steps in CanonicalizeLocaleList 8.c.ii-iv before calling the current CanonicalizeLanguageTag.

Before we get too much into spec details: Do others believe that exposing API as proposed by Zbigniew would be useful?

Norbert

On Jul 13, 2013, at 12:37 , André Bargull <andre.bargull at udo.edu> wrote:

> 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.

Correct. As currently specified, the CanonicalizeLanguageTag abstract operation assumes that its input is a String value that's a structurally valid language tag. An API cannot make such assumptions - it has to be ready to deal with any input, as well as the absence of input. It has to do something like the steps in CanonicalizeLocaleList 8.c.ii-iv before calling the current CanonicalizeLanguageTag.

Before we get too much into spec details: Do others believe that exposing API as proposed by Zbigniew would be useful?