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 <mario.loffr...@iit.cnr.it
<mailto:mario.loffr...@iit.cnr.it>> a écrit :
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<r...@fastmailteam.com>
A: j...@ietf.org
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.
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 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.
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
<Parte allegato al
messaggio.txt>_______________________________________________
regext mailing list
regext@ietf.org <mailto:regext@ietf.org>
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
