This chart compares styles of JSON Schema generation:
The differences between JSON Schema styles are:
WAPI and SWIFT use an abbreviated snake case form of the Message Definition’s name as the top object property. MixedType and StringArray use the verbatim Root Element as modelled & provide the verbatim name in a @name property.
WAPI uses @xmlns, and SWIFT use $id to hold an xmlns with a URN concatenating the Message Definition Identifier. MixedType and StringArray provide identifier components in separate properties.
WAPI and SWIFT do not include descriptions in the JSON Schema. MixedType and StringArray provide descriptions and omit the extraneous type, which is defined by the referenced item “$ref”.
MixedType encodes numbers as JSON Numbers. Be aware that some JSON libraries do not handle big decimals.
StringArray represents every element as an array of objects or strings, including Booleans. This has the benefit of providing consistent access to items irrespective of their multiplicity or type.
SWIFT omits the minItems in arrays.
SWIFT represents Element names in lower_snake_case.
The differences between JSON±LD SHACL & JSON Schema styles are:
JSON±LD is a seriliasation of an RDF graph model.
In order for SHACL to check the shape of the graph:
It requires a @vocab in a @context to specify members namespace.
The message objects’s @type is the message definition identifier.
It interprets a JSON array as links to each value in the array, so it doesn’t matter whether a single value is in an array or not.
JSON numbers are interpreted by JSON+LD as decimal, whereas JSON-LD treats them as binary floats, losing accuracy. Representing a decimal number in JSON-LD requires a value object.
JSON±LD supports prefixes as abbreviations of namespaces, whereas JSON Schema doesn’t handle namespaces. Provided the prefix is fixed, it is possible to generate JSON Schema that validate JSON±LD.