Thanks Norbert, that's great. I won't be able to get back to this project for another week or two (some stuff has come up) but will let you know if I have any questions. On Thu, Jan 10, 2019 at 2:52 AM Norbert Hartl via Pharo-users < pharo-users@lists.pharo.org> wrote:
Hi Eric,
Iâm late to the game but Iâm interested to talk abd cooperate. I implemented JSON schema [1] not long ago. This can also be used to add a mapping from object to json. It has also a type key inside the json object. I did it with an intermediate object. The JSONSchemaDefinition is a super type of all JSON schema types meaning one json object containing all keys of all types. I read the super type and then with a visitor I explode this super type into concrete type objects. As you say on writing I use the concrete objects. The asymmetry is also a bit tricky but in the end the best approach so far. So if you like we can talk. I think that it could be a good idea to think about how JSON Schema and JSON LD could fit together.
Norbert
[1] https://github.com/zweidenker/JSONSchema
Am 09.01.2019 um 22:27 schrieb Eric Gade <eric.gade@gmail.com>:
Hi Sven, thanks for the response.
Unfortunately since I'm working with a standard here, there is always going to be an explicit `"type": <foo>` attribute rather than having the key itself be the name of the type. I guess I'll stick to the two-pass read solution. But the writing solution can use the mapping so that saves a lot of trouble!
On Wed, Jan 9, 2019 at 3:14 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
Eric,
On 9 Jan 2019, at 00:34, Eric Gade <eric.gade@gmail.com> wrote:
Hey guys,
I'm toying with the idea of a Pharo implementation of ActivityStreams ( https://www.w3.org/TR/activitystreams-core/#introduction) which is based on a subset of JSON called JSON-LD (for "linked data").
While I do not believe this would entail creating a whole JSON-LD implementation, I do have a question about how to implement reading/writing/mapping to and from the core set of object types in the specification.
I am aware that giving any class #neoJsonMapping allows one to define the specifics of the mapping to and from objects of that class (I think this is super cool, by the way). The issue with ActivityStreams objects is that the "type" of object they represent is in the JSON itself as the property "type," for example:
``` { "@context": "https://www.w3.org/ns/activitystreams", "name": "A simple note", "type": "Note", "id": "http://www.test.example/notes/1", "content": "A simple note", "replies": { "type": "Collection", "totalItems": 1, "items": [ { "name": "A response to the note", "type": "Note", "content": "A response to the note", "inReplyTo": "http://www.test.example/notes/1" } ] } } ```
This refers to a top level ActivityStream object of type "Note" which we maybe want to parse into something like `ASNote`.
My core question is this: how can we get a NeoJSONReader to determine which type of object to create by checking for a "type" property as soon as possible in the process? Because this property can show up in any order, we won't know what type of object to create until it is encountered. What is the best strategy there?
Does the complexity suggest that we should simply parse incoming ActivityStream objects into the collection-and-dict default mapping and deal with creating the appropriate objects after that? In this case we could still use the custom mapping for the writing, which is not a problem since the "type" field will be associated with the class (ie, ASNote class
#type will respond with 'Note' and we can go from there).
Any thoughts or suggestions much appreciated!
You describe the situation correctly: NeoJSON operates in 2 modes:
(1) generating generic Arrays and Dictionaries (just like the spec)
or
(2) optionally mapping, stream based, directly, without intermediary representation, into domain instances (given a predefined static mapping)
Using NeoJSONObject instead of Dictionary is just a convenience (it being a more JS like object).
There is indeed another approach, using dynamic typing, that is not specifically supported in NeoJSON.
As you remark yourself, that requires an intermediary representation, so one could just as well use option (1) and convert 'manually' in a second pass.
That being said, it could/would be a nice addition to offer some support for this. Although there are multiple slightly different approaches. For example, there also is
{ "Point" : { "x" : 1, "y" : 2 } }
Instead of
{ "_type" : "Point", "x" : 1, "y" : 2 }
The key for the type/class can be different, the value can be anything, even 'com.java.graphics.Point'.
Note also that typically, there are no collection types (and these would be way more complicated).
Sven
-- Eric
-- Eric
-- Eric