Cool, so looks like the Jackson library affords a seamless way to deal with JSPointer’s as keys. Thanks for pointing to that test.
Jasdip From: Mario Loffredo <mario.loffr...@iit.cnr.it> Date: Tuesday, June 13, 2023 at 4:30 AM To: Jasdip Singh <jasd...@arin.net> Cc: "Hollenbeck, Scott" <shollenbeck=40verisign....@dmarc.ietf.org>, "jgould=40verisign....@dmarc.ietf.org" <jgould=40verisign....@dmarc.ietf.org>, "regext@ietf.org" <regext@ietf.org>, Tom Harrison <t...@apnic.net>, George Michaelson <g...@algebras.org>, Andy Newton <a...@hxr.us> Subject: Re: [regext] Thoughts on the fundamental premise of JSContact Hi Jasdip, Il 12/06/2023 22:24, Jasdip Singh ha scritto: Hello Mario, After reviewing the PatchObject data type [1] in JSContact, one question: How would the JSON serialization/deserialization work for a JSONPointer as a key (read: member name) in a PatchObject, given a programming language like Java does not allow a forward slash ( '/' ) in a variable name, AFAIK? It depends on how you deserialize the JSON content. A suggestion about how to implement the PatchObject in Java can be derived from its definition in JSContact: A PatchObject is of type String[*], and represents an unordered set of patches on a JSON object. Each key is a path represented in a subset of JSON pointer format [RFC6901]. Terms such as "unordered se" and "key" may suggest that the use of a Java Map can be the way to go to implemet PatchObject. After all, since you can localize every JSContact value no matter if its type is primitive, an object or an array and if the property to localize is a standard property or an extension, it would be inefficient to deserialize a PatchObject in an object whose members are fixed in adavance. In jscontact-tools, the "localizations" property is defined as in the following: Map<String, Map<String, JsonNode>> localizations; where JsonNode is the base class for all JSON nodes in jackson library. Serialization/deserialization takes place straightforwardly without customizations. FYI, you can find some examples of localizations handling by jscontact-tools at https://github.com/consiglionazionaledellericerche/jscontact-tools/blob/master/src/test/java/it/cnr/iit/jscontact/tools/test/localizations/LocalizationsTest.java . Hope it could be helpful. Yesterday I talked with Robert Stepanek and we agreed the PatchObject is more difficult to formally describe than to implement ;-) Best, Mario Jasdip [1] https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-11.html#name-patchobject On 6/9/23, 11:41 AM, "Andrew Newton" <a...@hxr.us<mailto:a...@hxr.us> <mailto:a...@hxr.us><mailto:a...@hxr.us>> wrote: ... TBH, it was the JSContact patchobject that made me re-examine this space. I don't know the requirements for CalExt, but the necessity to implement a JSON patching framework to parse postal addresses seems to me to be beyond what is reasonable for RDAP. James has also pointed out several times that the JSContact UID may not be a good fit for RDAP. ... -- Dott. 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
