Stream: implementers
Topic: Representing Generics in StructureDefinition
Mark Kramer (Jun 14 2018 at 12:17):
CIMI uses Generics to implicitly define classes in its logical model. An example is ClinicalStatement<T,C> where T and C are parameters. By specifying different parameters, you can define different classes -- without generating a concrete class. For example, ClinicalStatement<ProcedureTopic, PlannedContext> represents a clinical statement about a procedure that has been planned. If this generic were replaced by a concrete class, the class would be something like "ProcedurePlannedStatement". The advantage to CIMI is that it doesn't have to define all those concrete classes. Some people in CIMI insist Generics are a critical feature to retain if CIMI starts using StructureDef instead of ADL (I'm not in that camp). So, two questions: (1) are Generics of any interest to FHIR, (2) how could Generics be implemented in StructureDef if CIMI wanted to do that?
Grahame Grieve (Jun 14 2018 at 12:18):
we did used to have generics, but we got rid of them as needless complexity. Though we have some under cover genericness going on around resource references
Grahame Grieve (Jun 14 2018 at 12:18):
so the vestigial support we had for generics has gone the way of most vestigial organs.
Grahame Grieve (Jun 14 2018 at 12:19):
which amounts to saying, right now, we have no support for this at the type level
Grahame Grieve (Jun 14 2018 at 12:19):
but it's .... of interest
Grahame Grieve (Jun 14 2018 at 12:21):
however I remember all the pain in trying to run down all the loose ends associated with a full generics implementation too. That pain... is not of interest
Mark Kramer (Jun 14 2018 at 12:23):
All I can say is that certain CIMI members are going to resist moving from ADL to StructureDef if we don't have generics. Any suggestions on how to defuse this argument?
Grahame Grieve (Jun 14 2018 at 12:26):
since name calling probably won't help- tempting as it is when generics come into the picture - we should probably talk about requirements
Richard Esmond (Jun 14 2018 at 13:03):
I'm not the only person in CIMI who likes Generics, but I certainly one of them. (grin)
I like them because it allows my code generation stack to provide a smooth pathway to automymously expressing code, as opposed to my team having to write tha part of our stack - by hand.
I'm not claiming that Generics make my entire stack - automated... but they help make the mix of automated / manual coding a better shade of grey.
So, in my own code-stack - Generics have reduced my complexity, not increased it.
Grahame Grieve (Jun 14 2018 at 13:06):
then you probably only implemented part of the whole picture.
Claude Nanjo (Jun 14 2018 at 16:00):
In my case, I don't need to implement the generics. I map them to the representations in my target implementation language, e.g., Java or C#. Again, it is a question of requirements. If the language is intended to describe what is or is not allowed in a message, then choice is perhaps more explicit (I think). However, if the model is defined to also represent a logical model to use at the reasoning layer, then generics become pretty important if we are going to use standard programming languages rather than invent our own. I certainly would not want to implement that logic again. Many programming languages support generics rather than eliminate them as vestigial organs. This is probably because the requirements for FHIR are different than the requirements for CIMI which is completely understandable. This brings me to the question as to whether it is reasonable to insist that FHIR support generics.
Thomas Beale (Jun 14 2018 at 16:37):
Just noticed this discussion from links MK posted. Dumb question: is StructureDefinition intended as a modelling language, or a representation description method? It looks like the latter to me, which seems normal. But I'm unclear if people think it is going to formalise all the modelling semantics that a modelling formalism does. The simplest I have been able to get it is a combination of BMM (vastly simpler than UML) and ADL/AOM, including differential and inheritance flattening semantics. If someone else had built this, the concrete form would have been somewhat different, but at the end of the day I can't see that the general mathematical analysis or complexity level is ever going to be lower.
Thomas Beale (Jun 14 2018 at 16:41):
So I think the existential question is pretty simple: if CIMI wants to downgrade to something like a basic artefact representation formalism, SD may do what is needed. But if people want tools that understand things like typing, inheritance, composition, generics, overriding, and will machine analyse it, then you either build up SD to do that job, you use BMM/ADL/AOM, or you build a 3rd equivalent, and then build tools around that. These seem like the objective choices available to me...
Thomas Beale (Jun 14 2018 at 16:44):
Aside: one might have thought that after all these years, UML would do all that is needed. It doesn't, for reasons including these: http://www.openehr.org/releases/BASE/latest/docs/bmm/bmm.html#_current_state_of_the_art . And we are power users of MagicDraw, with an extractor that fixes broken bits of UML in our spec publishing toolchain. It's a great tool, it's just a horrible (and out of date) standard.
Grahame Grieve (Jun 14 2018 at 20:26):
if I follow your language - you implied a lot in a few words - that Structuredefinition is not a modelling language. And we haven't set out to define all the modeling formalisms. Partly that was the pain I was afraid of around generics: we can easily add support for type parameters - we had that. But my question is what the expectations around tools are. We want co-variance? we want full validation? we want publishing and validation and code generation that's fully consistent in all the corners of the intersections of generics (e.g. the java ? extends T syntax, mixins....). There's the simple parts of generics, and then there's the other parts....
Thomas Beale (Jun 15 2018 at 09:02):
It's no criticism of StructureDefinition; from what I can see it will do a certain type of job which is undoubtedly what it is needed to do. But doing a full modelling formalism is substantially more than that (as I've no doubt everyone here realises perfectly well). Generics is one thing, and it is quite tricky to get right - I only just upgraded it to work really properly in BMM with generic inheritance with open and closed parameters, as well as fixing some aspects of how generic properties get re-typed through inheritance covariantly changing concrete parameter classes. And so on. And that is of course without going near the horror that is Java generics. What I've engineered in BMM is what I think UML _should_ do if its generics were not broken.
Thomas Beale (Jun 15 2018 at 09:04):
But generics is just one thing. Getting differential representation, inheritance-flattening, redefinition, and so on is no simple thing. As Grahame often says, there's no hiding from true complexity, only pushing it to different places.
Grahame Grieve (Jun 15 2018 at 10:06):
but since that complexity has to live somewhere, the question is, where should it live?
Thomas Beale (Jun 15 2018 at 10:14):
Well that's the point: you have to have formalism(s) that do the work. That's what BMM+ADL/AOM do. You could re-engineer all that (somehow, maybe) based on UML with another layer (we did, called AML, it was fairly horrible), or on Ecore, but it's always going to come out roughly the same. The structures and semantics you need to do the job are pretty irreducible as far as I can see. I don't see for example any OOPL that magically does everything that people want in modern languages, but without any formal complexity.
Thomas Beale (Jun 15 2018 at 10:15):
I don't mind at all if HL7 doesn't want to use BMM/ADL any more, I'm just curious as to how it's going to obtain the modelling power I see people asking for without something of equivalent power. I may be missing something about SD; I have only looked at the FHIR resource page for it, maybe there is more I don't know about.
Last updated: Apr 12 2022 at 19:14 UTC
