How versioning of JSON data looks like #231
Conversation
follow argumentation here json-schema/json-schema#220 The reference to which JSON schema the JSON data belongs shall be handled by the user, NOT from inside the data. Also the validation against a JSON schema, or the mapping from data to schema shall be handled by the user. A convention (not determined by the json-schema) is that the JSON schema has `$schema`, the JSON data not.
albertmink
changed the title
|
Q: Where and how do we provide the mapping of JSON data to JSON schema? Two situation for which the mapping matters:
|
albertmink
force-pushed
the
amink/version-example-intf
branch
from
be357bc to
af1ddc7
Compare
albertmink
changed the title
|
|
||
| The format of object types will evolve over time. If a change to the format is considered incompatible, the version of the file format has to be increased. | ||
| The ABAP file format of object types will evolve over time. | ||
| For this purpose the JSON schema specifies the field `formatVersion` and the file itself, is named after the version. |
There was a problem hiding this comment.
Shouldn't it be $formatVersion? Sorry, if I missed the decision against $.
There was a problem hiding this comment.
I understood that @albertmink don't want to add the $. I was wondering whether it would help to indicate that formatVersion contains meta information about the object. However, both solutions would be fine for me.
doc/specification.md
Outdated
| One mandatory component of the type is the field `schema` which is translated to `$schema` in the JSON schema. | ||
| Its value in the `.json` files is the link given in the field `$id` of the JSON schema. | ||
| Furthermore, a `header` has to be supplied. | ||
| Fields `formatVersion` and `header` are mandatory on root level. |
There was a problem hiding this comment.
Wouldn't it be more consistent if the field in the ABAP type was called format_version? Then, the generator translates it to ($)formatVersion.
There was a problem hiding this comment.
See my comments. Especially, I agree to one of @wurzka's comments
| "description": "Format version", | ||
| "type": "string" | ||
| "const": "1" |
There was a problem hiding this comment.
I am not sure. Should we also add a type (like number or integer)?
Values would then be changed to 1 instead of "2".
There was a problem hiding this comment.
Change type to number is bad, because for JSON schema the following representation of integer 1 are equivalent
1 and 1.0 and 1.00 and others
|
Right now, we miss the adoption of the ABAP types documentation here |
Closes #53, closes #83
Discussion and reasoning in #53