Henry, You wrote directly to me:
> I wish to use JSON for type encoding between different language environments, > currently Squeak and Java. Unfortunately I cannot load the software in Pharo, > at this time. I brought NeoJSON over into my package to work locally, and I > made some changes. As you can see below, I want to use ASN1 Module style > mapping registrations as well as formal schema consumption. I also wish to > use Fuel style substitutions. However, I realize NeoJSON may already have a > substitution mechanism. > > The issue with substitutions while walking a graph of objects, and this is > what Fuel solves (though I looked at an earlier version and do not know how > it does so now) is that the graph needs to connect with proxies, then > resolved into substitutions, so it is three steps: proxy-connect, > substitutions, real-graph-connect. > > The reason I am reaching out, and seeing that this is August you may be on > vacation, is to feel your thoughts out about using JSON Schemas. One issue I > not is that the types get hardcoded and applied to data that has no $ref in > the data. This makes creation of a #anyOf, #allOf, #oneOf difficult as I am > unclear how discrimination occurs. > > I would love to hear your thoughts - I am 95% decided on using JSON. As you probably know, JSON is rather special in its simplicity. The original author refused to add certain elements to its specification, because he knew they would complicate matters too much. Nor does he support any of the large number of extensions that others propose(d). NeoJSON is in the first place a clean/modern implementation of a JSON parser/generator for this specification, specific for Pharo. NeoJSON tries to be as resource (time/space) efficient as possible. Because converting between domain objects and JSON is a frequent requirement, a simple mapping mechanism was added. It avoids intermediate representations. Since JSON is inherently untyped, it is not a very elegant mechanism. Especially in the area of collection/relations, the options are rather limited. Still, I think it has proven useful for many people. Refer to the documentation and unit tests to see what is available. I known very well that many schemes exist, none of these are supported as such. My answer to these feature requests is STON: it has a clean/general/elegant typing mechanism and support for cycles and structure sharing. I prefer to keep JSON very simple. It would certainly be interesting if others would write extensions to NeoJSON, similar to the ideas that you have. As long as it is a clean extension I would be totally OK with that, if necessary I will support small, compatible changes to NeoJSON itself to help you in your implementation efforts. Regards, Sven > On 13 Aug 2017, at 21:04, henry <[email protected]> wrote: > > Thank you, Stef. I sent to him email, conditioned on his enjoying his > vacations. > > - HH > > >> -------- Original Message -------- >> Subject: Re: [Pharo-dev] Add JSONSchemas to NeoJSON >> Local Time: August 13, 2017 2:53 PM >> UTC Time: August 13, 2017 6:53 PM >> From: [email protected] >> To: henry <[email protected]>, Pharo Development List >> <[email protected]> >> >> Hi henry >> >> Here is the email of sven Van Caekenberghe <[email protected]> >> >> He is probably on vacation else he would have replied. >> This is great if you can extend neoJSON it is a nice and important >> piece of software. >> >> Stef >> >> On Sat, Aug 12, 2017 at 10:04 PM, henry <[email protected]> wrote: >> > Is Sven still working on NeoJSON? I want to help expand it to use >> > JSONSchemas. >> > >> > https://spacetelescope.github.io/understanding-json-schema/ >> > >> > I was looking at ASN1Module in Cryptography... >> > >> > - HH >
