Re: Language Tags (WG last call on the Java API)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:54 PM 3/10/01 +0100, Michael Ströder wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> Section 4.3.5 continues:
>>    getAttribute(attrName, lang) returns the subtype that matches
>>    attrName and that best matches lang.
>> 
>> I believe "best matches" is inappropriate.  A lang option either
>> matches (case insensitively) or it doesn't.
>
>Sorry for jumping in so late without knowing prior discussion.

I just initiated this discussion, so I don't see how you
could be viewed as late.

>If lang is simply a string the term "best matches" is inappropriate
>indeed.

In this context, "best matches" refers to a matching
algorithm which requires interpretation of the structure
of the language code.  This is inappropriate as RFC 2596
specifically states:
   Language codes are case insensitive.  Implementations MUST NOT
   otherwise interpret the structure of the code when comparing
   two codes, and MUST treat them as simply strings of characters.


>But I think lang should be declared as an ordered list of
>language options.

That how RFC 2596 describes the use of Language
Tags in LDAP.  An attribute type description can
contain any number of language tag options (which,
per RFC 2251 option requirements, must appear in
ascending order).

>In this case "best matches" would make sense to
>me.

This I don't understand.  They are simply strings, so
the only matching that makes sense is a simple case
insensitive match.

>E.g. web interfaces get a list of preferred languages from the web
>browser. Would be handy to simply pass that list directly to
>getAttribute(attrName, langList). Otherwise I can imagine myself
>coding another wrapper method...

Well, I think that would require this API to interpret
the structure of the code.  While this may be appropriate
in other contexts, in the context of an RFC 2596 implementation,
it is not.

There are many different uses of language tags.  Gatewaying
between them is an application level problem.  This API is an
LDAP API, hence it should be consistent with LDAP's use of
language tags.