Sure you are right, but if you would like to have those TDO/TDS then you’ll end up with template dependent schema. See also Seref’s post here.
noted! That was also my suggestion in latest SEC meeting.
perhaps we can still have a generic schema?! - to be discussed later…
The thing is that RM canonical is not always suitable to be a REST-API resource (think for instance on EHR vs EHRSummary, or the issue with some RM-invariants). And we cannot leave it open-choice to clients; we need to be a bit more strict and specifying it. On the way we could also choose to optimize some of REST resources (using composition, or derivation) over their RM counterpart, but that still has to be specified as OpenAPI schema. If all these are done, then implementers may use various tools to generate code in the language of their preference as you also suggested - and my hope is openEHR CDRs will use and extend this OpenAPI spec with their own additions (extra endpoints, headers, statuses, etc) in a very easy and consistent way, while also having their own rendering styling and branding.
That’s all valid and important enough to have, but I would say not right now - rather as a second stage. In my opinion it is more important (and doable) right now to have a better and computable specifications for our REST. In any case, these are all valid points (goals) to discuss in a meeting.
I think it is something that we must have specified - it is not really an optional aspect.