Indeed, was not concerned about keys starting with ‘@’, given they are
deterministic unlike the dynamic JSONPointer strings as keys.
Thanks,
Jasdip
From: Mario Loffredo <mario.loffr...@iit.cnr.it>
Date: Tuesday, June 13, 2023 at 12:30 PM
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 13/06/2023 16:01, Jasdip Singh ha scritto:
Cool, so looks like the Jackson library affords a seamless way to deal with
JSPointer’s as keys. Thanks for pointing to that test.
It's not a feature provided only by Jackson library. As I wrote in my previous
reply, it all depends on the object of the programming language you want the
JSON content to be deserialized into/serialized from.
If you need to deserialize a JSON object into an instance of a Java class, you
can:
- use the basic features provided by your JSON library if all of the member
names in the JSON object are already valid in Java;
- customize the deserialization to obtain valid Java member names.
Customization can be accomplished through commonly provided methods such as
using annotations, overriding the basic deserialization methods, and others.
With regard to my implementation of PatchObject, a Java map key can contain a
JSONPointer expression so it's an example of the first use case.
An example of the second use case is the handling of the JSContact @type and
@version properties: their names are not valid in Java but can easily be turned
into valid ones by using the Jackson @JsonProperty annotation (see the
following excerpt from the Card class)
@NotNull
@JsonProperty("@version")
@VersionValueConstraint
@Builder.Default
String _version = "1.0";
Best,
Mario
Jasdip
From: Mario Loffredo
<mario.loffr...@iit.cnr.it><mailto:mario.loffr...@iit.cnr.it>
Date: Tuesday, June 13, 2023 at 4:30 AM
To: Jasdip Singh <jasd...@arin.net><mailto:jasd...@arin.net>
Cc: "Hollenbeck, Scott"
<shollenbeck=40verisign....@dmarc.ietf.org><mailto:shollenbeck=40verisign....@dmarc.ietf.org>,
"jgould=40verisign....@dmarc.ietf.org"<mailto:jgould=40verisign....@dmarc.ietf.org>
<jgould=40verisign....@dmarc.ietf.org><mailto:jgould=40verisign....@dmarc.ietf.org>,
"regext@ietf.org"<mailto:regext@ietf.org>
<regext@ietf.org><mailto:regext@ietf.org>, Tom Harrison
<t...@apnic.net><mailto:t...@apnic.net>, George Michaelson
<g...@algebras.org><mailto:g...@algebras.org>, Andy Newton
<a...@hxr.us><mailto: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
--
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
