In order to not kidnap the thread about @NeoEHR’s cool generators I’ll clarify some thoughts here instead, where I believe the core of this discussion fits better.
@borut.jures and @thomas.beale I am not sure I explained my point well enough in OpenAPI schemas generated from BMM files - #9 by erik.sundvall when refering to @heath.frankel’s comment from 2012 on the wiki page https://openehr.atlassian.net/wiki/spaces/spec/pages/4915205/Ocean+EhrGate+-+Composition+Builder+programming+example
Yes developers/integrators need to learn a little bit about openEHR basics (but not much) if they e.g. have a template-specific use-case that is one of their first tasks to interact with an openEHR system.
However it would be great if they did NOT have to switch tooling or start using openEHR-specific path-based ways of interacting with components like the one suggested in the 2012 wiki page or the more elegant/compact toJson() method described by @borut.jures in OpenAPI schemas generated from BMM files - #10 by NeoEHR
By tools/methods they are already used to, I mean…
- for integrators/informaticians creating and maintaining integrations: low code tools like Altova MapForce or Mirth as described in Graphical data mapping tools supporting openEHR? (these tools work best if supplied with a template specific schema with user friendly node names derived from the template labels - TDS is one such approach, a similar way to do JSON schema for the “structured” (JSON tree) simplified format described as structSDT in the end of section 3.2 of a spec would also be a great option for such tools
- for software developers: a template-specific litte library of classes with names derived from the template labels. TDO is/was such an approach, template specific openAPI definitions would do the same job in a more modern and programming language-neutral approach. Then they can just generate and import the library/classes and keep using their favourite editor/IDE and get syntax higlighting, auto completion, validation etc based on the template (Instead of string based path/key approaches where errors often are only found at runtime).
So it’s not that we would try to “hide” everything in openEHR, it’s about making the integrator and developer experience more efficient and less error prone.
Edit: @Seref pointed out in a recent SEC-meeting that the simplifications in TDOs etc stopped somewhere around the openEHR data-type lower levels, and there reused a generic part for different use-cases/templates. Perhaps @seref or somebody else that is used to working with this could explain further in a few sentences?