Decisions to take
Core data representation
Issues:
- Keys
- atom
- Values
- String
- atom
- ISO, easy to read write and process
- Limits (length, number, atom-gc)
- Needs unnatural
true
,false
andnull
- string (if Prolog has such a type)
- Unambiguous and compact
- Non-portable
- Often requires atom_string/2 to create an atom
- string(CodesOrChars)
- ISO
- Expensive (wrt memory)
- Often requires atom_codes/2 to create an atom
- atom
- integer
- Prolog integer
- What about bounds?
- float
- Prolog float
- What about +-Inf, NaN
- What about overflows SWI: Controlled by IEEE754 support (Prolog flags)
- true, false, null
- If String is not an atom, use and atom.
- @(true), @(false), @(null) Janus compatibility
- ‘NULL’(Var) Database
NULL
semantics. Unclear whether that applies to JSON in general.
- Objects
- SWI-Prolog dict
- Janus {key:value, …}
- json(ListOfValues)
- Key: Value
- Key= Value
- Key- Value
- Key(Value)
- String
Options
Base on Janus
- Decide on
null
->@(null)
. how does this relate to@(none)
? - Come up with a library for accessing (nested) objects.
- Find keys
- Find using path to indicate nesting SWI: Value = Dict.get(a/b/…)
- Return default if not found SWI: Value = Dict.get(…, Default)
- Raise error if not found SWI: Value = Dict.Key[.Key]*
- Add keys
- Merge objects SWI: Dict.put(New). Adds keys, replaces values.
- Select sub-objects SWI: _{k1:V1, k2:V2} :< Dict
- Translate to popular Prolog formats, e.g.
- pair list
- assoc
- …
- Find keys
Type based conversion
- Define transformation rules in Prolog, e.g., {x:X,y:Y} <-> point(X,Y)
- Use JSON Schema?
- E.g., convert enum value to atom, normal string value as above
- Extend schema with conversion annotations.
Base on one of the above
No obviously best candidate (IMO)