feat: json schema for version 0.2.0

[StefanFl]

JSON Schema is a great way to check if an OpenVEX document is compliant with the specification.

This is still a draft pull request, because:

• The maintainers of the OpenVEX specification need to decide if this is a helpful contribution.
• The JSON Schema worked with my OpenVEX documents, but I would like to see more testing by the OpenVEX maintainers.
• If the JSON Schema will be accepted, it shall be mentioned in the README.md file.

[sschuberth]

• The maintainers of the OpenVEX specification need to decide if this is a helpful contribution.

IMO it clearly is, as it also helps to auto-generate code for writing out VEX documents in different programming languages.

[puerco]

Hey @StefanFl thanks a lot for this contribution it is of course super valuable! The JSON schema is something we've been meaning to write for a while now. Let me take a look at it and I'll add some early comments.

[StefanFl]

I have changed some formats to from urito iri, which is closer to the specification.

[StefanFl]

@sschuberth , @puerco There is one thing in the specification I don't understand: According to https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md#component-fields the fields @id, identifiers and hashes are all optional. Could I create a (sub)component without any of these? That would be an empty product. Or should it have a conditional requirement?

[sschuberth]

Or should it have a conditional requirement?

Just guessing, I believe you must have at least on of these, as either single one should be enough to uniquely identify a component.

[StefanFl]

Or should it have a conditional requirement?

Just guessing, I believe you must have at least on of these, as either single one should be enough to uniquely identify a component.

At least one of @id or identifiers would make sense to have. Just the hashes might not be enough.

I can implement this in the JSON Schema, but this would be more strict than the specification.

[StefanFl]

Or should it have a conditional requirement?

Just guessing, I believe you must have at least on of these, as either single one should be enough to uniquely identify a component.

At least one of @id or identifiers would make sense to have. Just the hashes might not be enough.

I can implement this in the JSON Schema, but this would be more strict than the specification.

Now at least one of @id or identifiers is required for (sub)components.

[StefanFl]

I have made a small fix. From "either a machine readable justification label or a free form text impact_statement" I thought these two attributes are mutually exclusive. But the example shows, that both are allowed together.

[StefanFl]

And I have included a reference to the JSON Schema in the README. From my point of view the PR is ready to be merged after your review.

[sschuberth]

Just for the record, I was running the schema through a code generator for Kotlin, which created compilable code, so I guess the schema is syntactically valid 😺

[StefanFl]

Hi guys, anything you need from me to get the pull request accepted?