Stream: committers
Topic: Code Generators
Brian Postlethwaite (Aug 11 2018 at 00:52):
Just an FYI that I'm doing a pre-run of the code generator for the .net client to ensure that there are no new surprises in there.
Brian Postlethwaite (Aug 11 2018 at 01:22):
Yup, quite a few issues in here thanks to the changes, working through them now.
Brian Postlethwaite (Aug 11 2018 at 01:39):
For properties that are deprectated (I'm looking at you OperationOutcome.issue.location) is there more than just the prefix in the short description to mark that in the StructureDefinition - considering adding the [Obsolete] attribute in the code generated so that developers are warned accordingly. And should this really be a developer warning vs hard error.
Brian Postlethwaite (Aug 11 2018 at 01:40):
(and should I put the definition into the compiler warning, or is that co-incidental that its covering the reason why it was deprecated.)
Brian Postlethwaite (Aug 11 2018 at 03:42):
Almost clear now, have a couple of new issues that need to resolve in the generator (spec is fine)
For string types we generate a native string property with the name of the fhir property, then a secondary property that is the FHIR datatype that has the name (property)"Element", so if there happens to be another property that has that name, there is a clash in the code generated. (easy enough to sort out).
The new one that popped out is OperationDefinition.referencedFrom
source
and sourceElement
Brian Postlethwaite (Aug 11 2018 at 03:48):
Have come across a single issue in the spec @Grahame Grieve
The valueset http://hl7.org/fhir/ValueSet/device-status
is not in the expansions.xml which is used by the Device resource.
(Will try again in-case it was a partial change coming through, but just a heads up)
Grahame Grieve (Aug 11 2018 at 03:50):
I should populate the extension for the deprecated element. that would be
http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status
Grahame Grieve (Aug 11 2018 at 03:51):
let's change sourceElement. that's just messy cause the same issue occurs in lots of implementations
Grahame Grieve (Aug 11 2018 at 03:51):
sourceId not sourceElement
Grahame Grieve (Aug 11 2018 at 03:52):
I'll look at the expansion issue post freeze.
Brian Postlethwaite (Aug 11 2018 at 03:55):
Have the a similar issue with the Expression
metadatatype.
It has a property called expression
, that we uppercase the first letter making it have the same name as the type.
Should that really be value
?
Grahame Grieve (Aug 11 2018 at 03:57):
I have less sympathy on this one.
Grahame Grieve (Aug 11 2018 at 03:58):
but I'm open to discssion.... @Bryn Rhodes do you have an opinion?
Brian Postlethwaite (Aug 11 2018 at 04:01):
I'm not too stressed, I can add a rule around it, but thought at least a heads up to other generators
Brian Postlethwaite (Aug 11 2018 at 04:08):
(And we already handled that case for resource types, just not datatypes, so copied across, no problem now)
Brian Postlethwaite (Aug 11 2018 at 04:15):
So Code generation for the dotnet client is ok, with just the 2 issues remaining.
- device status expansion missing
- source and sourceElement in OperationDefinition
Will leave the generation alone till tomorrow morning now.
Bryn Rhodes (Aug 11 2018 at 20:42):
Sorry for the dealy, I don't feel too strongly about it, but I generally dislike value
for an element that isn't the value
element of a "primitive", it leads to constructs like value.value
, which is pretty confusing.
Grahame Grieve (Aug 12 2018 at 02:36):
@Bryn Rhodes 7 hours left - are you good?
Bryn Rhodes (Aug 12 2018 at 02:40):
I have all substantive changes applied, yes
Brian Postlethwaite (Aug 15 2018 at 05:02):
In reviewing the output from the code generator, what should I be expecting to see for Age, Count, Duration and Distance?
Are they now full types, or profiles? I think its suggesting they aren't profiles anymore, but types, and just derived from Quantity, are there any others in this bucket that I should be concerned with?
(updating the code generator - again)
Brian Postlethwaite (Aug 15 2018 at 05:03):
Therefore the wire format will be valueAge etc when used.
Grahame Grieve (Aug 15 2018 at 05:21):
yes they are full types
Brian Postlethwaite (Aug 17 2018 at 01:10):
So from a normative standpoint, the code generators should be all go to output the new formats?
I just tried generating and the Device status still isn't in the expansion.xml
Brian Postlethwaite (Aug 17 2018 at 01:10):
(before we close off the core spec)
Grahame Grieve (Aug 17 2018 at 01:25):
no I still haven't got to that
Brian Postlethwaite (Aug 18 2018 at 10:46):
Is this the time where I ask again? (do I need to log a task for it?) Device Status in expansions.xml - or do I just check after the versioning and rebuilding exercise is done)
Grahame Grieve (Aug 18 2018 at 10:48):
It’s sorted now
Last updated: Apr 12 2022 at 19:14 UTC