Separating Models from Implementation

[erik.sundvall]

@damoca

GraphQL … query language … includes every bit of information of the RM, it would be a responsibility of the data consumer to ask for the information or data points they want. I think it is the most flexible approach.

I agree that GraphQL would be interesting, but to live up to developer’s mental models of it, they (at least the ones here at Karolinska) would likely want to be able to think that there is an active data store behind the scenes where you can pull up a composition and interact with it read+write on a specific field, or on a subtree in chunks, via GraphQL using “simplified” template-specific names + whatever other RM things that are unconstrained/unmentioned by the template. To do that I think a contribution builder approach would be good, where either an existing or new blank COMPOSITONs could be instantiated, read and modified and then, when finished, written back. Can we continue GraqphQL-discussion in that thread?