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,falseandnull
 
- 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 NULLsemantics. 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)

