FYI. Please provide feedback on calsify.
Best, Mario -------- Messaggio Inoltrato -------- Oggetto: [calsify] JSContact: alternatives to "localizations"? Data: Wed, 23 Apr 2025 13:53:52 +0200 Mittente: Robert Stepanek <[email protected]> A: [email protected]Sometimes we get feedback that the JSContact Card "localizations" property is complicated to implement. The complexity is said to come from the requirement to implement patches using JSON pointers.
Mario and I revisited the design choices that led to the current definition of the "localizations" property. Our requirements were and are to stay compatible with vCard as much as possible, and as vCard allows to basically localize any TEXT-typed property, we want to provide the same versatility also in JSContact. In addition, we want it to be simple to determine if a Card contains any localizations and also would prefer localizations to be represented in a compact format.
We think that in light of these requirements the current definition is preferable over the alternatives, and we intend to keep "localizations" as-is. The most often mentioned alternative is to define the "localizations" property not at the top-level of a Card, but for each object type that has at least one property that can be localized. For example, a Name object, an Address object, a NameComponent or AddressComponent, all would have their own "localizations" property.
In this alternative design, there would indeed be no need for nested JSON pointers in the PatchObject. However, unless we allow all current and future object types to contain the "localizations" property, we do not meet the same flexibility that vCard localizations provide. But defining the "localizations" property as _both_ a top-level and object-specific property would make it more complex to process localizations than it currently is. Lastly, to determine in this alternative design if a Card contains any localizations would require one to traverse the complete Card to identify if any localizations are present. We think that this does not reduce complexity, it only spreads it across the Card object.
Should one still not want to support nested JSON pointers in localizations, we define in jscontact-profiles <https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-profiles-00.html#name-patchobject-keys> how to restrict PatchObject keys.
If you have an idea how to meet the localization requirements as outlined in this mail with another design, feel free to discuss it on this list.
Thanks, Robert
_______________________________________________ calsify mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
