Hi,
After spending hours trying to convince various tools/projects to generate source code from the openehr json schemas, I finally gave up.
The schemas are truly extensive, a huge amount of work must have gone into these, so thanks a lot to Code24 for the initial effort and all the other contributors who brought the schemas to their current state.
Am I the only one who tried to use these in the same way we use XSDs? I’m really fighting the urge to express my feelings about json and its ecosystem in really colourful language at the moment…
So if there is something out there that works with these schemas to generate code and perform data binding, I’d really love to learn what framework/tool that is.
Forms can automatically be generated from json schemas with input bindings with something like https://github.com/rjsf-team/react-jsonschema-form
There are more options like this for angular and Vue. In most cases the schemas need to be modified a little before they can be consumed by such tools. Is this what you’re looking for?
Thanks for your reply. Unfortunately, no, that’s not what I’m looking for.
What I need is to provide json schema(s) to a tool and get back a set of POJOs/POCOs etc. This is a very common practice in XML space, based on XSDs, using JAXB for example.
Similar tools seem to exist for JSON schema, but I could not get anything to work in the .NET space, or on the JVM for that matter, using the openEHR json schemas.
The schemas look really well designed, so it appears to be a weakness of the tools and I’m looking for any tools which may have been used for this purpose successfully.
Yes, I have. They don’t work to generate code, and because of the way JSON Schema handles polymorphism it is never going to work for that purpose.
Actually the OpenEHR JSON Schemas do not handle polymorphism at all, which means they are also not usable for validation until https://github.com/openEHR/specifications-ITS-JSON/issues/8 is fixed. I created an alternative json schema, generated directly from BMM, as part of archie, to solve that problem.
However, OpenAPI is very suitable for this problem. Actually you could create a full openEHR rest interface, fully automated, for many languages, if we wrote the API specification in that language. I already auto-generated all the models, because it is just a very small addition above JSON Schema. So, see https://github.com/nedap/openehr-openapi , it includes documentation on how to generate the actual models.
Thanks @pieterbos . Thanks a lot for the openapi link, I think that’s what I was hoping json schema would allow me to do.
I’m a bit confused though, you say (“Yes, I have”) but then say they don’t work to generate code. then you say they’re currently not useful for validation. So what did you used them for?
Yes, I have generated code from it, but I then found that the code it generated was missing the type discriminator, and some other things. I looked at why, and found that json schema does not have a type discriminator column. OpenAPI is JSON schema with some features removed, and a type discriminator column added, so I switched to that.
JSON Schema is perfectly suited for validation, even for the OpenEHR model, and again, I tried it with the official schemas.
The problem is, the official OpenEHR JSON Schema does not take polymorphism into account. That means that the items attribute of a CLUSTER, which is of type ITEM, does not get validated, and nothing below that, because the types ELEMENT and CLUSTER are not validated where it says ITEM in the model. That means it stops validating really early and cannot be used.
Making that work is perfectly doable, as I have done in https://github.com/openEHR/archie/blob/master/tools/src/main/java/com/nedap/archie/json/JSONSchemaCreator.java . That means I do use JSON Schema for JSON validation, for example in testing the Archie JSON example instance generator. However, I do not use the official schemas.
I cannot fix the official schemas - they are autogenerated with closed source code, and fixing them by hand is not a good idea, so all I can do is to offer a complete replacement schema, without all the documentation.
Thanks. That’s interesting. Where do the official schema come from then?
As things stand, it looks like what we provide as official schemas are not usable for the primary purpose of schema: validation. I don’t want to use strong statements but my understanding is we have a broken ITS artefact in our hands. Am I wrong?
I would say they are incomplete, more so than broken - if the type discriminator plus correct type reference combinations were to be added, they would work as intended.
Well, …we are all human, resources are not unlimited.
Current schemas were generated by me, initially for some experiments I’ve done inside Code24, for form generation/validation. That did not worked out as initially planned (partially due what Pieter mentioned), so I was just to tried to ‘finish’ them by adding doc/specs from UML models, hoping that it could be used to generate models or used inside ITS-REST specs - which also did not worked out as wished.
Work on json-schema is not finished, @pieterbos is right, I still have to evolve it, but currently I’m busy in other openEHR projects. However, I would really like to come back on this, and have a chat and collaborate with you or others having already experience on this field to eventually have better official openEHR json-schema.
You don’t need to remind me about the finite nature of resources I was just curious how these came to be, that’s all. On one hand, I’m terrified of what’s happening to json schema as a formalism, on the other hand, I cannot see how I can personally avoid it or we can avoid it as software industry, so we’ll have to use some form of it.
It looks like Swagger/OpenAPI will be the flavour that’ll be most relevant, at least for the day to day tasks of software dev, so that’s worth considering.
Openapi and json schema are actively discussing/collaborating, so someday there may be support for these kinds of things in json schema as well.
Actually a json schema code generator with polymorphism could be possible right now, but it would have to check commonly used patterns and translate that, instead of a clear marker on what that field is for. And I haven’t found any that do this last time I checked.
Active discussion about that topic here: https://github.com/OAI/OpenAPI-Specification/issues/2143
. handrews is one of the json schema specification authors. They are discussing replacement of discriminator with a ‘selectBy’ keyword, that looks like it would improve both code generation and validation, moving towards one specification instead of openAPI being an extension to json-schema, as it is now in version 3.1.
@Seref It is a complete disaster. For a long time I could ne believe my eye, as I was assuming after like 30 years after corba/xsl/etc. this should be a pretty solved problem. I wasted days wading through this pile of crap and failed to find a single working stack for a simple use case:
I have a wire protocol of messages defined as json arrays. These came into existence de-facto, not really by design. Now I want to contain their structure in a json schema. To a specification I can validate against. And from that I want to create strictly typed objects, on all sides, sender and receiver, in variouis languages. In java you would say POJOs maybe. Just that, and that should be an easy automatic process. So it is NOT about the REST api, nor any existing specification I want to map. I am looking for good best practices easy well desgined tools,
I’ll spare you my rant about json ecosystem not even being able to reinvent the wheel and all that…
The best I could achieve was using the code generating tool offered by OpenApi, i.e. ex-Swagger. That one generated code using the schema generated by Archie as input. However, I remember finding a bug in the generated code (!) and having a discussion with Pieter about how to fix it, but that’s where I left it.
In any case, the largest body of work related to this requirement appears to be the code generator tool for OpenApi(API?) so I suggest you take a look at the Archie >> OpenAPI_Tool pipeline.
it is indeed surprising how bad it can be. I did this with IDE/Corba for the first time, and one should thought it is a solved problem. But nope, looks like three steps forward, two steps back for the last 20 years. Companies tries to corner the market and lock you in in their IDEs, in the need for monetizing business plans, that’s the driving factor it seems to me.
