Stream: conformance
Topic: snapshot depth
Chris Grenz (Jun 30 2016 at 16:14):
Is there some reason that snapshots include id and extension children of backbone element but not on other elements? At the root of a resource this makes sense since id, extension, and modifierExtension are included via base inheritance (id here is Resource.id and not Element.id). But BackboneElement is just a type and seems to be treated specially in that its children are included. This is in contrast to say Identifier elements where children are not included.
Chris Grenz (Jun 30 2016 at 21:22):
In other worlds, why is:
ValueSet.compose.extension in the snapshot and,
ValueSet.identifier.extension not?
Grahame Grieve (Jun 30 2016 at 21:33):
because ValueSet.identifier is a reference to another type which does include those in it's snapshot. If you look at the profiles that walk into a data type, you'll see that in that case, those elements are included.
Chris Grenz (Jun 30 2016 at 22:30):
ValueSet.identifier references the Identifier type, and Identifier.extension is included in that type profile's snapshot. Similarly...
ValueSet.compose references the BackboneElement type, and BackboneElement.extension is included in *that* type's snapshot.
I don't see the difference....
Chris Grenz (Jun 30 2016 at 22:31):
I'm ok with "just because"....but as I'm working out the canonical snapshot rules, I need to understand...
Grahame Grieve (Jun 30 2016 at 22:33):
well, the reason they're different is because the snapshot walks into the backbone elmenet, but doesn't walk into the identifier
Chris Grenz (Jun 30 2016 at 22:34):
yeah...I don't "walk" into either type in my case...
Grahame Grieve (Jun 30 2016 at 22:34):
you can tell whether a type is being referenced or desribed by whether there's any child elements. No child elements - see the type for furthe details. Child details: ignore the type, and use what's inline
Chris Grenz (Jun 30 2016 at 22:34):
e.g. I don't generate the compose.extension because I don't retrieve the type's children...
Grahame Grieve (Jun 30 2016 at 22:34):
you have to walk into a backbone element, because it's abstract
Chris Grenz (Jun 30 2016 at 22:35):
I would only include compose.extension if the local profile includes extension in the differential
Grahame Grieve (Jun 30 2016 at 22:36):
then you're wrong, I'm afraid.
Chris Grenz (Jun 30 2016 at 22:37):
:) maybe...I don't see clear reasoning why BackboneElement's children get included.
Chris Grenz (Jun 30 2016 at 22:37):
And Element's children don't.
Grahame Grieve (Jun 30 2016 at 22:37):
in the snapshot, it's all or nothing - either you reference a type, or you inline the type - all of the type
Chris Grenz (Jun 30 2016 at 22:38):
Ah....
Grahame Grieve (Jun 30 2016 at 22:38):
if you can find anywhere where the profiles don't follow that rule, then I'll have to fix something
Grahame Grieve (Jun 30 2016 at 22:39):
we don't want to have the situation where you inline of some a type and then something has to figure out what the intent is in overlap/gap somewhere. it's all or nothing
Chris Grenz (Jun 30 2016 at 22:39):
ok....that really sucks for my tooling, but now I understand....
Chris Grenz (Jun 30 2016 at 22:41):
value[x] variations don't count?
Grahame Grieve (Jun 30 2016 at 22:42):
not sure what you mean by 'count' there.
Chris Grenz (Jul 01 2016 at 14:43):
For instance, if my extension allows boolean and dateTime types for value[x], and I include a valueBoolean element in my differential, should the snapshot also create a valueDateTime element?
Grahame Grieve (Jul 01 2016 at 21:40):
that's a good question. I'm not really sure.
Chris Grenz (Sep 01 2016 at 22:59):
@Michel Rutten What does Forge do with this?
Michel Rutten (Sep 02 2016 at 10:03):
@Chris Grenz Forge development branch now uses the FHIR.NET API for snapshot expansion.
Here's an example of the currently generated snapshot:
https://simplifier.net/noAuditLog/noAuditEvent
As you can see, currently the generated snapshot always expands elements of type BackboneElement to include extension and modifierExtension child elements.
We received some feedback from Simplifier customers about this. Apparently our users are considering this to be noise and would like these elements to be hidden in the rendering. From a user's perspective, a rendering only needs to include these elements if the profile actually contains associated differential constraints:
- If the profile introduces one or more specific extensions
- If the profile specifies custom cardinality on the extension element (e.g. extension.max = 0)
- If the profile specifies custom constraints on the extension slicing entry (e.g. slicing.rules = closed)
Lloyd McKenzie (Sep 02 2016 at 13:44):
How you display the snapshot is up to you, but the snapshot itself definitely needs to contain them. (And it would be good to have at least an indicator that elements from abstract parents have been hidden.)
Lloyd McKenzie (Sep 02 2016 at 13:45):
Also, keep in mind that it's not just extensions that can get profiled. I would say that if there are *any* constraints/overrides on an element (even adding a usage note to "id"), you should make sure you render it.
Chris Grenz (Sep 02 2016 at 14:38):
Agree with Lloyd - if it's a valid child of an element that is being expanded, it must be included.
Michel Rutten (Sep 02 2016 at 16:50):
Indeed, I see why. So the logic to hide/show "noisy" infrastructural elements should be incorporated into the rendering logic.
Michel Rutten (Sep 02 2016 at 16:51):
e.g. if the element is inherited from DomainResource/BackboneElement and it has no associated differential constraints, then hide the element in the UI.
Last updated: Apr 12 2022 at 19:14 UTC
