Stream: implementers
Topic: should date 'value' element appear in snapshot?
Jonathan Mew (Jul 05 2017 at 13:28):
I am trying to understand whether some output from Forge is correct (NHS Digital's DSTU2 version).
We have profiled the Patient resource. In the resultant snapshot, there is now a Patient.birthDate.value element present, containing the regexes for the date datatype. In the differential, this element doesn't appear at all.
By contrast, in our profiled version of the Practitioner resource (which includes an element of type date at Practitioner.birthDate) there is no Practitioner.birthDate.value element in the snapshot or differential. Likewise in Argonaut's profile of Patient, there is no Patient.birthDate.value element.
My specific question is: should the patient.birthDate.value element have been included in the snapshot?
In case it makes any difference, we have sliced Patient.birthDate.extension and added the patient-birthTime extension.
For context, I am working on displaying our profile information and deciding whether/how to display the Patient.birthDate.value element. Simplifier seems to ignore it, but if I follow that example, I'll need to figure out the general case for what to ignore.
Ewout Kramer (Jul 06 2017 at 15:18):
In case it makes any difference, we have sliced Patient.birthDate.extension and added the patient-birthTime extension.
Yes, that does make a difference! If you walk into an element (in this case you are walking "into" Patient.birthDate to the "extension" child, the snapshot generator will need to include all siblings in the snapshot, since the original reference to just the type (date) is now replaced by an full include of all the children of that type - just so to be able to constrain extension!
Jonathan Mew (Jul 06 2017 at 15:42):
Ah thank you @Ewout Kramer, in that case I can implement an appropriate rule to hide it.
I'm a little confused though - the Patient.birthDate node still has type "date", so I'd expect the constraint to still implicitly be there. How does including the value explicitly help to constrain the extension?
Ewout Kramer (Jul 06 2017 at 15:50):
The snapshot is supposed to have "everything" so a tool like yours (or mine - the validator) does not need to go out and fetch external definitions. In my validator I get a performance improvement - I'll validate what's in the snapshot and I don't need to fetch the type "date" too - it would probably result in duplicate error messages on top of that. So, including value helps me validate the contents of the constrained Patient.birthDate!
Jonathan Mew (Jul 06 2017 at 16:17):
@Ewout Kramer Let me check my understanding: when validating against a snapshot, if a primitive is somehow extended/constrained, you can't rely on the default constraints on the type. Instead you need to inspect all of the additional constraints AND the original constraints and infer a set of rules for valid data.
In that case, it is more efficient to explicitly include the original type constraints in the snapshot so you can just iterate over the child nodes and apply their constraints, rather than separately fetching the rules for the type itself.
I still don't think I've quite understood - I would expect the rules for built-in primitive types to be readily available to the tool, in which case the performance improvement would be negligible. And wouldn't duplicate error reporting be more likely, not less, now that you encounter the date type (with its implicit constraints) as well the value node?
Or, on a related note, wouldn't it be a similar improvement to explicitly write out every primitive's constraints, not just those you have stepped into?
Thank you for your help and patience!
Ewout Kramer (Jul 07 2017 at 07:00):
Yes - it is true that you still might need access to the core SDs and also external SDs referred to in <profile> in the typeref - the validator certainly does. While rendering though - you might not need to do it, just show the contents of the snapshot and/or the differential. Grahame and I have defined an extension which we can put in the snapshot to signal which parts have been changed by the differential, so you could have a "total" view, yet display which parts have changed. I don't think the snapshots in the spec have it, we will have simplifier allowing you to re-generate the snapshot and make this visible soon.
The logic around snapshots has grown from DSTU1, where we did not have the notion of a "differential", there was just the snapshot with "all" data in it. In DSTU2 we introduced the differential, which -obviously- has just the differences (i.e. as the author probably created them) and the snapshot remained unchanged, just keeping all siblings. If we'd have just the changed constraints in the snapshot, it would actually start to be a kind of differential.
Jonathan Mew (Jul 07 2017 at 08:56):
Hmmm. Since the type is still present on the parent in the snapshot, it doesn't seem to me that you would lose/hide any information by adding the extension and not explicitly adding the constraint (so your snapshot should still be 'complete' without adding the regexes). However, I'm sure your code makes good use of the value element's presence, in any case :)
Anyway, thank you very much for some insight into how Forge deals with snapshots, primitives and extensions!
Last updated: Apr 12 2022 at 19:14 UTC
