Subject: [regext] Fwd: [Jmap] JSContact: how to localize content

From: Mario Loffredo <[email-masked]>
Date: Wed, 21 Jul 2021 14:50:20 +0200

I would like to invite the WG members to provide feedback about a topic 
that might impact on future RDAP implementations.

If you are interested, please reply on JMAP mailing list.

Any contribution is welcome.

Thanks a lot,

Mario

-------- Messaggio Inoltrato --------
Oggetto: 	[Jmap] JSContact: how to localize content
Data: 	Wed, 21 Jul 2021 14:12:38 +0200
Mittente: 	Robert Stepanek <[email-masked]>
A: 	[email-masked]

At the joint CALEXT/JMAP interim meeting 
<https://datatracker.ietf.org/doc/minutes-interim-2021-jmap-01-202104150300/> 
in April we discussed options how localize JSContact values. This can be 
useful to provide names and addresses in multiple languages within the 
same contact. In VCARD this is achieved with the LANG parameter.

We would now like to find consensus how to achieve this in JSContact.

*Current approach*
The current scheme in the spec defines a LocalizedString object for 
fields that can be localized. A LocalizedString has a value and optional 
localized variants of this value:

"addresses": {
"addr1": {
"city": {
"value": "Tokyo",
"localizations": {
"jp": "東京"
}
}
} }

The idea is to keep values and their localizations close. It is built on 
the assumption that the majority of values will have localized variants.

*Proposed approach*
Multiple participants in the interim meeting vouched for replacing the 
current approach with the one defined in section 4.6.1 
<https://datatracker.ietf.org/doc/html/rfc8984#section-4.6.1> of the 
JSCalendar RFC. That is, the "localizations" property is a JSON object 
where the keys are language tags, and the values are patch objects which 
overwrite one or multiple properties within a contact.

A main benefit  of this is to reuse for the same approach in both JMAP 
calendars and contacts. It treats localized content as the exception, 
not the norm, and the data types should reflect this. Any property value 
can be localized (except if the spec explicitly forbids it). In 
contrast, only values of LocalizedString can be localized in the current 
approach.

This an example how to localize a single address field:

"addresses": {
"addr1": {
"city": "Tokyo",
}
},
"localizations": {
"jp": {
"addresses/addr1/city":"東京"
}
}

To fully localize an address, one would write:

"localizations": {
"jp": {
"addresses/addr1": { "city": "東京" }
}
}

*Finding consensus*
Mario and I would now like to know which approach you prefer, or any 
other you would like to propose. Our goal is to reach clear consensus. 
We look forward to your feedback.

Thanks,
Robert

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 21 Jul 2021 09:37:08 -0400

I’m not on jmap list, but I have to say that their proposed approach is much more complicated to decode by standard json decoders. I would say don’t do it.

Marc.

> Le 21 juill. 2021 à 08:50, Mario Loffredo <[email-masked]> a écrit :
> 
> I would like to invite the WG members to provide feedback about a topic that might impact on future RDAP implementations. 
> 
> Mittente:	Robert Stepanek <[email-masked]> <mailto:[email-masked]>
> A: 	[email-masked] <mailto:[email-masked]>
> 
> At the joint CALEXT/JMAP interim meeting <https://datatracker.ietf.org/doc/minutes-interim-2021-jmap-01-202104150300/> in April we discussed options how localize JSContact values. This can be useful to provide names and addresses in multiple languages within the same contact. In VCARD this is achieved with the LANG parameter.
> 
> Current approach
> The current scheme in the spec defines a LocalizedString object for fields that can be localized. A LocalizedString has a value and optional localized variants of this value:
> "addresses": {
>   "addr1": {
>     "city": {
>       "value": "Tokyo",
>       "localizations": {
>         "jp": "東京"
>       }
>     }
>   }
> }
> The idea is to keep values and their localizations close. It is built on the assumption that the majority of values will have localized variants.
> 
> Proposed approach
> Multiple participants in the interim meeting vouched for replacing the current approach with the one defined in section 4.6.1 <https://datatracker.ietf.org/doc/html/rfc8984#section-4.6.1> of the JSCalendar RFC. That is, the "localizations" property is a JSON object where the keys are language tags, and the values are patch objects which overwrite one or multiple properties within a contact.
> 
> A main benefit  of this is to reuse for the same approach in both JMAP calendars and contacts. It treats localized content as the exception, not the norm, and the data types should reflect this. Any property value can be localized (except if the spec explicitly forbids it). In contrast, only values of LocalizedString can be localized in the current approach.
> 
>     "addresses/addr1": {
>       "city": "東京"
> Finding consensus
> Mario and I would now like to know which approach you prefer, or any other you would like to propose. Our goal is to reach clear consensus. We look forward to your feedback.
> 
> Thanks,
> Robert
> <Parte allegato al messaggio.txt>_______________________________________________
> regext mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 26 Jul 2021 09:54:56 +0200

Hi Marc,

thanks a lot for your quick reply. Robert and I are trying to consider 
all the aspects to figure out the best solution so every contribution to 
the discussion is welcome.

I implemented some tests about how feasible the alternative approach is 
by using both JSON deserialization/serialization and JSONPointer 
capabilities provided by existing Java libraries.

I found out that managing localizations of String values is not so 
difficult while localizations of varying objects seems to me very 
complicated to treat.

I'll report that and other conclusions to JMAP just to make the 
attendees to consider the matter from as many perspectives as possible.

That being said, I warmly invite you, like anyone who is interested, to 
manifest your opinion within JMAP where decisions about JSContact are taken.

Best,

Mario

Il 21/07/2021 15:37, Marc Blanchet ha scritto:
> I’m not on jmap list, but I have to say that their proposed approach 
> is much more complicated to decode by standard json decoders. I would 
> say don’t do it.
>
> Marc.
>
>> Le 21 juill. 2021 à 08:50, Mario Loffredo <[email-masked] 
>> <mailto:[email-masked]>> a écrit :
>>
>> I would like to invite the WG members to provide feedback about a 
>> topic that might impact on future RDAP implementations.
>>
>> Mittente: 	Robert Stepanek<[email-masked]>
>> A:	[email-masked]
>>
>>
>>
>> At the joint CALEXT/JMAPinterim meeting 
>> <https://datatracker.ietf.org/doc/minutes-interim-2021-jmap-01-202104150300/>in 
>> April we discussed options how localize JSContact values. This can be 
>> useful to provide names and addresses in multiple languages within 
>> the same contact. In VCARD this is achieved with the LANG parameter.
>>
>> fields that can be localized. A LocalizedString has a value and 
>> optional localized variants of this value:
>> "addresses": {
>> "addr1": {
>> "city": {
>> "value": "Tokyo",
>> "localizations": {
>> "jp": "東京"
>> }
>> }
>> } }
>> The idea is to keep values and their localizations close. It is built 
>> on the assumption that the majority of values will have localized 
>> variants.
>>
>> *Proposed approach*
>> Multiple participants in the interim meeting vouched for replacing 
>> the current approach with the one defined in section4.6.1 
>> <https://datatracker.ietf.org/doc/html/rfc8984#section-4.6.1>of the 
>> JSCalendar RFC. That is, the "localizations" property is a JSON 
>> object where the keys are language tags, and the values are patch 
>> objects which overwrite one or multiple properties within a contact.
>>
>> A main benefit  of this is to reuse for the same approach in both 
>> JMAP calendars and contacts. It treats localized content as the 
>> exception, not the norm, and the data types should reflect this. Any 
>> property value can be localized (except if the spec explicitly 
>> forbids it). In contrast, only values of LocalizedString can be 
>> localized in the current approach.
>>
>> other you would like to propose. Our goal is to reach clear 
>> consensus. We look forward to your feedback.
>>
>> Thanks,
>> Robert
>> <Parte allegato al 
>> messaggio.txt>_______________________________________________
>> regext mailing list
>> https://www.ietf.org/mailman/listinfo/regext 
>> <https://www.ietf.org/mailman/listinfo/regext>
>
-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo