Generating json schema is supported in Archie, as long as you have a BMM input. In several flavours of json schema. So go ahead. It does specify OPT 2 in json as well.
OpenAPI can be a bit tricky. Yes, you can specify the format in json schema, and tools can validate the input. But in order to generate code from that, you need code generators that support polymorphism. As far as I know, code generators for json schema that support polymorphism do not exist, and are hard to write. So, the move to 3.1 probably does very little to help openEHR.
That has more or less been the story for myself, @sebastian.iancu and @pablo when we worked on this (Sebastian did most of the work).
Polymorphism had support for OpenAPI but it was not good enough to be reliable across mainstream languages. There are multiple ways of expressing inheritance in OpenAPI and code generated from those kept having issues.
As far as I know, neither json schema nor OpenAPI are reliable sources for code generation at this point in time.
@sebastian.iancu worked on two flavors (and tried many alternatives) of the JSON schemas for the REST APIs, I think one was focused on data validation (syntax) and the other one on code generation (correct types and hierarchies, etc).
For the work I do in our CDR, I only use the data validation one for checking the commits in JSON. I think the schemas I use were generated from the BMMs at some point, though I think I fixed some errors then merged all together in a single file JSON Schema for convenience (it’s easier to validate against a single schema than many schemas that have references between them).
I’m sorry I can’t add much value to this discussion right now, I personally don’t see a use case for code generation based on schemas yet. For instance, what I did in the openEHR Toolkit to generate JSON examples is all based on the OPT 1.4 model, the RM and the JSON schema, but not using the schema directly, basically I’ve built a JSON serializer for the RM that complies with the JSON schema.