Subject: Re: [scim] Multi-lingual support for some textual attributes

From: Andreas Åkre Solberg <[email-masked]>
Date: Fri, 2 May 2014 12:28:44 +0200

First, there is not that many attributes in the core schemas where I see a need for multi-lingual support. One of few exceptions is the displayName of a Group. To support my use case I am prepared to add new attributes to hold the translation of attributes in the core schema.

I have no problem with having to add extension schemas, but am worried about the fact that there seem to be no good way to do that for multi-lingual strings, because there is no suitable attribute type.

If I have understood complex attributes right, it is aimed at predefined sub-attributes whose property names are from a definite and limited set. One would typically be interested in using a language code in as an object property, but even if you restrict it to ISO 639–1 values alone, there is almost 200 languages codes, and it would not scale to define sub-attributes for all these langauges in the schema.

Other alternatives quickly becomes encoding JSON within a string or using binary / base64 encoding. Both, unattractive for communities interested in building protocols or extensions on top of SCIM.

An alternative to getting translatableString as a data type defined in the core specification would be if SCIM allowed custom attribute types to be defined in extensions. May be that is considered legal already?

-- 
Andreas Åkre Solberg
UNINETT AS - http://uninett.no

On 29 Apr 2014 at 11:43:02, David Möbius ([email-masked]) wrote:

My major concern is that the solution would most likely require turning multi-lingual attributes into complex attributes (as you describe).  This makes the protocol significantly more complex.  Though that said, recent changes with the API draft now make this much easier to support since you can now update specific sub-attributes of complex attributes.

Could your case be handled using attribute extensions?  In this case the core schema value would be the default or preferred language of the user or the owner of the resource (e.g. group).  The extension would then contain the complex attribute structure you require. 

Do we need a multi-lingual attribute definition? —> so that at least multi-language attributes are handled consistently?

---

From: Phil Hunt <[email-masked]>
Date: Fri, 2 May 2014 09:28:31 -0700

I think if we did it for groups you would also have to deal with Users specifically the “name” attribute which has sub attributes: formatted, familyName, givenName, middleName, honorificPrefix, honorificSuffix. For Users there is also displayName and nickName.

As for the language tags, the current IETF best practice appears to be RFC5646 (which I recently updated core-schema-04 to support - see attributes locale, preferredLanguage, etc).

Adding locale specific values does complicate parsing and creates other problems like what to do for service providers that do not support localization (because they don’t understand do thus can’t preserve localization).

BUT, adding localization as a schema extension would seem to be problematic too.  The SCIM extension model lets you add new attributes, but not necessarily new types, nor sub-attributes to other schema attributes.

I’d like to see some JSON representations and proposals. We can then evaluate whether 
a. localized values can be handled through extensions,
b. a new data type (localizedString/locString/translatableString) is needed OR just permit any String to have localized values,
c. the size of the problem.

It would be great to get some proposals.  I wonder what JSON structures have been developed in this area?

Could either of you put together some text together (along with some JSON alternatives) for the group to consider?

Phil

@independentid
www.independentid.com
[email-masked]

On May 2, 2014, at 3:28 AM, Andreas Åkre Solberg <[email-masked]> wrote:

> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim