JSON file format, define how serialization should work

[larshp]

suggest:

• add comment regarding the schema version
• add comment regarding use of lowerCamelCase(?) for naming of JSON fields

[larshp]

~max field name length = 30 characters, upper case characters counting as 2 characters~

update: not relevant anymore due to the ABAP approach

[larshp]

plus compression/initial value handling

[schneidermic0]

plus compression/initial value handling

I am not sure, whether this make sense in all places. Consider such a boolean value for instance to specify whether a BAdI can be implemented by multiple BAdI implementations or only by one: https://github.com/SAP/abap-file-formats/blob/05ef0284856122e796eda519b5116ac63e3f98f5/file-formats/enhs/examples/z_aff_example_enhs.enhs.json#L17

[larshp]

having one convention/rule makes it transparent, no special cases

if initial values are skipped in the json, then it might have impact on the type design, so instead of

TYPES multiple_use type abap_bool.

then

TYPES: BEGIN OF ENUM use,
  single   VALUE 'single',
  multiple VALUE 'multiple',
END OF ENUM use

is an option to always have the value in the json, note how this makes it part of the type design, and not a special case in json handling

[schneidermic0]

Initial values are not rendered (only if the field is explicitly annotated by $required or $showAlways) see following sections in the specification document:

• https://github.com/SAP/abap-file-formats/blob/main/doc/specification.md#required-fields
• https://github.com/SAP/abap-file-formats/blob/main/doc/specification.md#always-shown-fields

When #173 is merged, I think only the schema version question is open.