Stream: conformance
Topic: Invalid sliceName on SimpleQuantity core def?
Michel Rutten (Aug 10 2017 at 12:54):
We recently received a bug report on the .NET snapshot generator concerning unexpected slice names in the snapshot.
After closer analysis, I noticed that the core definition of the SimpleQuantity datatype specifies an explicit slice name on the root element:
<differential>
<element id="Quantity:simplequantity">
<path value="Quantity" />
<sliceName value="SimpleQuantity" />
<!-- ... -->
Currently, because of the way the snapshot generator works, profiles that reference the SimpleQuantity datatype automatically inherit the slice name from the core definition. This confuses the profile author and causes unexpected tooling issues.
This seems incorrect? As in general, I never expect slice names to occur in core defs and neither on root elements.
Suggestions:
1) Remove the invalid slice name from the root element of the official SimpleQuantity datatype definition in the FHIR spec
2) Implement additional rule in the snapshot generator to generate warnings when slice names are found on core definitions and/or root elements. The snapshot generator could then pro-actively delete/ignore the specified slice name. This would automatically detect and fix any future errors in the core spec.
Lloyd McKenzie (Aug 10 2017 at 15:13):
Agree that there should be no sliceName on the root element. Grahame - is this something we can fix with a patch?
Michel Rutten (Aug 10 2017 at 15:16):
Maybe the official build could run a simple validation rule to verify that core defs do not contain any non-null slice names? This way, future regressions would be detected immediately.
Lloyd McKenzie (Aug 10 2017 at 15:30):
Well, the true validation is that sliceName should only appear when there's slicing in scope - either from the current resource definition or on the path inherited from the parent
Grahame Grieve (Aug 10 2017 at 21:19):
I'm not convinced that this is wrong. I think we should talk about this in San Diego
Chris Grenz (Aug 10 2017 at 21:20):
This has been discussed at length in the past - it's not valid to have a sliceName on the root element.
Chris Grenz (Aug 10 2017 at 21:21):
It's an artifact from pre-STU3 where "name" was used to simply label things.
Grahame Grieve (Aug 10 2017 at 21:22):
i don't think it's so simple. In this case, the slice name is used to make the ids on the ElementDefinition unique across the buld
Lloyd McKenzie (Aug 10 2017 at 21:42):
Why should element ids be unique across the build? They're only supposed to be unique in the context of a model. It makes no sense to use a sliceName when you're not slicing.
Grahame Grieve (Aug 10 2017 at 22:05):
it's useful, if you're taking a data element based look at the spec, to have unique names for the data elements
Richard Townley-O'Neill (Aug 11 2017 at 00:13):
What does the slice name (value="SimpleQuantity") give you that is not in the id (id="Quantity:simplequantity")?
Chris Grenz (Aug 11 2017 at 00:14):
The unique name is http://hl7.org/fhir/StructureDefinition/SimpleQuantity#Quantity
Grahame Grieve (Aug 11 2017 at 00:16):
id="Quantity:simplequantity" - that is the slice name right there
Chris Grenz (Aug 11 2017 at 00:16):
@Richard Townley-O'Neill the id only includes the :simplequantity part if the sliceName is populated (elementdefinition ids are calculated).
Richard Townley-O'Neill (Aug 11 2017 at 00:23):
Is that a requirement of FHIR (hard to change) or a convenient way of generating the id (maybe easier to change)?
Grahame Grieve (Aug 11 2017 at 00:24):
yes and yes
Lloyd McKenzie (Aug 11 2017 at 04:14):
Data elements aren't elements. I'm fine with you prefixing the data element with the model id if the root element isn't the model id. But you don't need to mess up the element ids to do that, nor do you need to abuse sliceName. sliceName's semantics are clear. The way you're using it is clearly in violation of the definition and also unnecessary.
Michel Rutten (Aug 11 2017 at 08:55):
I tend to agree with Chris & Lloyd on this issue. FHIR requires that element id's are unique within the context of a resource (except repeated in snap/diff). However there is no guarantee or expectation that generated id's are globally unique. (Ab-)using the root element slice name for this purpose causes unexpected behavior in derived profiles downstream, due to the way snapshot generation currently works. I'm not sure if a snapshot generator could handle this reliably, as I suspect that this could introduce ambiguities...?
Michel Rutten (Aug 11 2017 at 09:03):
Maybe we could allow this by introducing a special rule stating that slice names on root elements are never inherited by the referencing profile when applied as an element type profile?
But frankly, I'm reluctant to introduce additional complexity to slicing... rather not.
Last updated: Apr 12 2022 at 19:14 UTC
