On Jul 13, 2013, at 12:37 , André Bargull <[email protected]> wrote:
> On 7/13/2013 8:48 PM, Andy Earnshaw wrote: >> On Sat, Jul 13, 2013 at 1:05 PM, André Bargull <[email protected] >> <mailto:[email protected]>> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
