You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some of the Base/Conformance resources we had to employ a trick to make the POCOs and ITypedElement work when the datatype of a property changed from FHIR release to FHIR release.
E.g.
[FhirElement("size", InSummary=true, Order=70)][DeclaredType(Type =typeof(UnsignedInt), Since = FhirRelease.STU3)][DeclaredType(Type =typeof(Integer64), Since = FhirRelease.R5)][DataMember]public Hl7.Fhir.Model.Integer64 SizeElement
or
[FhirElement("requirements", InSummary=true, Order=40)][DeclaredType(Type =typeof(FhirString))][DeclaredType(Type =typeof(Markdown), Since = FhirRelease.R5)][DataMember]public Hl7.Fhir.Model.FhirString RequirementsElement
As you can see, we chose one type to be "the" type in the POCO, but the "type from the specification" is encoded in the attributes. This is also the type that is surfaced in ITypedElement.InstanceType. Since the validator and the fhirpath engine used the ITypedElement information, an operation like ofType() works correctly. However, now we're moving from ITypedElement to POCO's, this trick no longer works, since FhirPath and the validator will know the POCO type, not the ITypedElement instance type.
This issue is not necessarily a showstopper, as it only concerns a few properties and generally our shared code will be resources that are almost normative. But now "POCO is king" the POCO also has the responsibility to reflect the actual type.
So, I propose that for these few properties, we make the type in the POCO DataType, just like with the choice types, but we will not mark it as a choice type. This means the deserializers (and the ITE->POCO) will be able to set this property to the actual type encountered on the wire.
For the users, this is slightly more involved, as there's now not a single type anymore. We'll have to add generated comments to the property which type is expected for which version of FHIR (which we do already mostly). We might even consider having the "helper properties" (as these are all primitives) to be the "latest" (and probably final) datatype, or have two helpers, one suffixed R3. Or if that is confusing, have no helpers. Then people have to chose.
Like so:
[FhirElement("requirements", InSummary=true, Order=40)][DeclaredType(Type =typeof(FhirString))][DeclaredType(Type =typeof(Markdown), Since = FhirRelease.R5)][DataMember]public Hl7.Fhir.Model.DataType RequirementsElement
public string Requirements =>(setsRequirementsElementas Markdown)publicstringRequirementsString=>(setsRequirementsElementas FhirString)
The text was updated successfully, but these errors were encountered:
For some of the Base/Conformance resources we had to employ a trick to make the POCOs and ITypedElement work when the datatype of a property changed from FHIR release to FHIR release.
E.g.
or
As you can see, we chose one type to be "the" type in the POCO, but the "type from the specification" is encoded in the attributes. This is also the type that is surfaced in
ITypedElement.InstanceType
. Since the validator and the fhirpath engine used the ITypedElement information, an operation likeofType()
works correctly. However, now we're moving from ITypedElement to POCO's, this trick no longer works, since FhirPath and the validator will know the POCO type, not the ITypedElement instance type.This issue is not necessarily a showstopper, as it only concerns a few properties and generally our shared code will be resources that are almost normative. But now "POCO is king" the POCO also has the responsibility to reflect the actual type.
So, I propose that for these few properties, we make the type in the POCO
DataType
, just like with the choice types, but we will not mark it as a choice type. This means the deserializers (and the ITE->POCO) will be able to set this property to the actual type encountered on the wire.For the users, this is slightly more involved, as there's now not a single type anymore. We'll have to add generated comments to the property which type is expected for which version of FHIR (which we do already mostly). We might even consider having the "helper properties" (as these are all primitives) to be the "latest" (and probably final) datatype, or have two helpers, one suffixed R3. Or if that is confusing, have no helpers. Then people have to chose.
Like so:
The text was updated successfully, but these errors were encountered: