Stream: methodology
Topic: How we should represent type choice
Grahame Grieve (Oct 21 2019 at 16:08):
Presently, when committees decide that an element is polymorphic, they simply list the types that can be used.
In the heirarchical table, and the XML and Json templates, we do the same thing: simply list the set of types that can be used
Grahame Grieve (Oct 21 2019 at 16:09):
But in the UML we do something different: we declare the element to be of type "Type" and list the choices as a set of constraints in a stereotype
Grahame Grieve (Oct 21 2019 at 16:10):
but our decision during the development of R4 that some of the Types can have modifierExtensions complicates that a lot....
Grahame Grieve (Oct 21 2019 at 16:10):
And Type is not a declared element.
Grahame Grieve (Oct 21 2019 at 16:10):
generating code to get this right is actually pretty tricky
Grahame Grieve (Oct 21 2019 at 16:10):
because of the modifier extensions.
John Moehrke (Oct 21 2019 at 16:40):
because of the modifier extensions.
Solution is to not allow modifier extensions... I think I have said that before
Grahame Grieve (Oct 21 2019 at 16:41):
I lost on that motion
Grahame Grieve (Oct 21 2019 at 16:42):
They are allowed on some types
Grahame Grieve (Oct 21 2019 at 16:43):
The problem is that Dosage is declared as a specialization of BackboneElement, but this is not a Type
Grahame Grieve (Oct 21 2019 at 16:44):
That is, if Type is declared as an abstract specialization of Element and generalises the common re-usable data types. Which is the notional but undocumented intent of Type
Grahame Grieve (Oct 22 2019 at 22:25):
So let's start with the abstract types. This is an classic OO model for what's going on with the abstract types, which is not explicit in the specification:
Grahame Grieve (Oct 22 2019 at 22:25):
Grahame Grieve (Oct 22 2019 at 22:26):
I'd like to make that model explicit
Richard Townley-O'Neill (Oct 22 2019 at 23:14):
Do you see all of the non-primative types as being descendants of BackboneType, or only some, such as Dose?such as Dose?
Grahame Grieve (Oct 22 2019 at 23:19):
only some. Currently labelled as descending from BackboneElement, but they actually can't unless you allow for polyheirarchy, which I think we should avoid
Grahame Grieve (Oct 29 2019 at 22:29):
Follow up on this: MnM agreed today to make this change - to include the UML diagram in the specification, and to change the structure definitions to support it, and to then consult implementers to see if anyone is concerned about this as a breaking change
Note that the only sense I know that this is a breaking change is that it will impact on the code generators for the reference implementations etc
Last updated: Apr 12 2022 at 19:14 UTC
