JSON serialization
Closed this issue · 4 comments
According to json.org:
"JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate."
KMF/JSON serialization definitely considers the machine side... Here are a few suggestions which could also consider the human-side of JSON:
1 - Omitting "eClass":"qualified:name:of:metaclass" when the class to instantiate is unambiguous (i.e. with a composite reference pointing to a class with no sub-classes). I think EMF does that in XMI serialization. The goal would be to make the JSON more natural to write. The limitation (the reason why it should be an optional "optimization") is that it would make the serialization less robust (typically if a sub-class is introduced in the metamodel, the existing serialized models are screwed).
2 - Use more natural paths instead of these ugly XMI-like paths. Again, the goal is to make the JSON more natural to write. We could e.g. let the designer specify for each EClass an attribute that can serve as ID, then use qualified name (constructed according to the composite references from the top) to refer to object. Something like mtTypeDefinition.myProvidedPort (assuming "name" is defined as ID), instead of //@typeDefitions.10/@required.2. Again, this optimization should be optional and to be decided by the designer, who should ensure he could ensure namespace-like IDs.
Adding such "human syntactic sugar" things has previously been done in other projects (like Kermeta).
It leads to an increase in complexity of algorithms because of the exception cases introduced by this sugar, and this also influence the performance of loads/save/clones.
When using JSON to exchange data for the generation of a web page, generally produces a quite small JSON with a standard formatting; thus easy to read.
When using JSON to serialize models, it becomes as unreadable as XMI and this is normal. XMI has not been done to be human readable, an the JSON we serialize neither. Maybe we just lack of a reflexive tool to open the JSON as a tree, more readable by human for debug purposes...
What do you think ?
Let's first say this feature request is far from being mandatory for the upcoming release...
I could agree the "eClass" stuff is something that could introduce further issue in terms of performances and robustness (even though robustness is not so much of an issue since KMF would regenerate the loader/serializer if the metamodel changes).
For my second point on the path, I believe that in the case of small languages (metamodels) and/or small models, JSON provides a good solution for rapid prototyping in a light-weight environment (no need to wait 5 minutes to boot eclipse, 2 minutes to generate Eclipse plugins, and 5 more minutes to boot the second Eclipse running those plugins, and 2 minutes before it crashes for a perm gen exception, 2 more minutes to add more memory, 5 more minutes to reboot it). In the same time, you could have written 5 small json files assessing some properties of your language. I believe the paths would greatly simplify the writting of these files.
But that is just my opinion
Hello,
I also agree that the eClass attribute is less readable but exception in the loader take a lot time and make the global process weaker.
In an other hand PATH instead of XMIRef don't cost any thing I improve I lot the human readability of the generated JSON file. A related task is to add the default ID generation when no ID attribute is defined in the ECORE MetaModel file. This is mandatory to have a systematic process to replace XMIRef by KMFpath.
A take this feature request :-)
François