JSON PSL/Runtime Config
Opened this issue · 5 comments
The current YAML setup is pretty fragile and can be confusing (e.g. when to make a map or a list).
With all the potential options coming up in the Supporting/Neural models, we need a configuration that is more robust.
A JSON setup would be pretty nice.
We should make a JSON format and deprecate the YAML format in the next release.
Here is a draft of the proposed format:
https://docs.google.com/document/d/1Xz5qX8rL_nlx3r7peKkeTX5vvRBbtdWmlmAZQtLHafw/edit?usp=sharing
This has been expended to include more than just config, but also rules, and general PSL config.
The single JSON
for everything configuration is pretty good idea, specially when someone wants to run PSL CLI from his code or other process, but my experiences showed me that it lacks of human readability/writablity as it has many rules for a JSON text to be valid. There is also lack of comments in a standard way and it makes it worse. I believe you can still use YAML for handling List
and Map
. Also there is nothing better than XML for your needs.
YAML is out, we are generally not fans and the subtle differences between list and maps have made it hard on our users.
XML is out, it is way too verbose and not human-readable enough.
There are plenty of JSON libraries that will allow comments (and allow for more flexible syntax (like trailing commas)).
I still insist on using YAML because it has less syntax stuff and fewer special characters and it is only using whitespace for distinction which makes it more readable. You can simply handle Map
as described in https://www.baeldung.com/yaml-map-pojo and the differences between a Map
and a List
is pretty obvious:
A List
is in this form:
yamlconfig:
list:
- item1
- item2
- item3
- item4
while a Map
is like:
yamlconfig:
map:
key1: value1
key2: value2
key3: value3
key4: value
There are plenty of JSON libraries that will allow comments
I usually don't use things that are not implemented according to standards since they are fragile and may change soon. Also, these implementations usually have no good community for maintaining them.
We will still support YAML, but all our descriptions, examples, and efforts will be in JSON going forward.
Any YAML config will be directly converted to JSON and worked with in that form.