Stream: implementers
Topic: Eliminating StructureDefinition.contextType for extensions
Lloyd McKenzie (Dec 12 2017 at 20:38):
The documentation for how to populate StructureDefinition.context was a little lacking. As I was writing up a proposal for how to improve it, I started questioning the value of having contextType at all. contextType isn't necessary to be able to parse the contexts - we can already figure out whether we're looking at a resource or resource path, a data type or data type path or an extension or extension path. Really all it serves to do is prevent you from having an extension that could appear in a mixture of data type paths and resource or extension paths. And I'm not clear on why we actually need such a constraint.
If we eliminate StructureDefinition.contextType, you could send as many contexts as you liked - the name of any resource or data tyep or path of any resource element or data type element or the URL of any extension or other profile, optionally followed by a '#' and the id of an element within the profile. So string or string.id or Address.type.coding or Patient or Patient.name or http://hl7.org/fhir/StructureDefinition/patient-birthPlace or http://hl7.org/fhir/StructureDefinition/patient-citizenship#Extension.extension:code or even http://hl7.org/fhir/StructureDefinition/bodyweight#Observation.valueQuantity
And of course we could use * if we wanted an extension to be useable anywhere.
In addition to simplifying the model a bit, this proposal would open up a few capabilities we don't have now:
- you could define extensions and allow them to be used in both specific data types as well as specific resource locations or extensions
- you could define extensions and allow them to be used only in the context of resources or data types that adhered to specific profiles
It would however loose the ability to say "can appear at any position in any data type, but not at the root of a resource or in a backbone element" or "can appear at any position inside an extension, but not anywhere else". I'm not aware of any use-case where we'd want to do either of those things though.
This is an FMM5 artifact, so we'd need to get feedback from the implementer community. Do we want to make this change? @Chris Grenz @Michel Rutten @Ewout Kramer @Grahame Grieve
Michel Rutten (Dec 13 2017 at 10:17):
Hi @Lloyd McKenzie, your proposal seems perfectly reasonable. This change would be almost backwards compatible, except for a few academic/theoretical cases. Limited impact on existing logic.
(we could even allow complex fhirpath expressions... but added complexity probably outweighs the benefits)
Grahame Grieve (Dec 13 2017 at 11:32):
I just discovered an issue related to this.. when an extension has a context type of "Element" and a path of "*", can you use it on a the root element of a resource?
Ewout Kramer (Dec 13 2017 at 11:50):
Could we use "*" or "Element" or "Resource" as first part of the path to enable these cases?
Michel Rutten (Dec 13 2017 at 12:13):
I was thinking along the same lines. Could we?
Lloyd McKenzie (Dec 13 2017 at 15:49):
Well, right now, a context type of "Element" makes no sense, because we say that when you declare the context type of a parent, that doesn't include the children
Lloyd McKenzie (Dec 13 2017 at 15:50):
Unless the intention is that contexts apply to "extending" children, but not to "constraining" children?
Lloyd McKenzie (Dec 13 2017 at 15:51):
Is there a wildcard capability in FHIRPath? I'd prefer to align with FHIRPath as much as possible when defining contexts
Lloyd McKenzie (Dec 18 2017 at 19:50):
This thread sort of died. My last question is sort of targeted at either @Grahame Grieve or @Bryn Rhodes
Grahame Grieve (Dec 18 2017 at 19:51):
there isn't a wild card capability in that sense, I think
Lloyd McKenzie (Dec 18 2017 at 20:09):
Is there any value in adding such a capability?
Grahame Grieve (Dec 18 2017 at 20:31):
don't know
Lloyd McKenzie (Dec 18 2017 at 21:00):
@Bryn Rhodes, your thoughts?
Ewout Kramer (Dec 18 2017 at 21:15):
What kind of wildcard capacity are you looking for exactly?
Bryn Rhodes (Dec 18 2017 at 21:42):
I have always wondered why we have contextType and would support removing it. For the wildcard case, to specify that sort of thing in signatures we use the type Any, would that work?
Bryn Rhodes (Dec 18 2017 at 21:43):
In fact, isn't context just a special case of a typeInvariant? And if you had no typeInvariant (or context) then it would apply everywhere. And with typeInvariant, you could express the more complex use cases, though I'm not sure we actually need that kind of power.
Lloyd McKenzie (Dec 18 2017 at 22:43):
So say Any or an explicit path and don't worry about being able to constrain to "only data types" or "only resource elements"?
Grahame Grieve (Dec 18 2017 at 22:59):
Actually, here, it should be Resource, not Any. This is strictly typed. Or Element for any contained element
Lloyd McKenzie (Dec 18 2017 at 23:56):
Well, the issue with specifying an abstract type is we explicitly say that specializations aren't included. So if you say an extension applies to "string", it won't apply to "code" or "oid". That also means that if you say it applies to "Resource", it wouldn't apply to "DomainResource" or "AllergyIntolerance"
Lloyd McKenzie (Dec 18 2017 at 23:56):
We can't have it both ways...
Grahame Grieve (Dec 19 2017 at 02:01):
do we explicitly say that? where?
Lloyd McKenzie (Dec 19 2017 at 02:05):
Comments on StructureDefinition.context:
"...Note that a context of "string" doesn't mean that the extension can be used with one of the string patterns such as "id" etc."
Grahame Grieve (Dec 19 2017 at 02:06):
ok that's a specific call out, not a general thing. So we indeed have it both ways
Lloyd McKenzie (Dec 19 2017 at 02:28):
The language doesn't make it clear that it's a specific call-out. I read it as a rule that would hold equially for integer or any other type.
Lloyd McKenzie (Jan 26 2018 at 23:40):
Should we tighten the language to note that this non-inheritance only applies to constraints of "string"?
Ewout Kramer (Feb 16 2018 at 14:26):
I don't think this made it into a GF issue, seems worthy of one....
Ewout Kramer (Feb 16 2018 at 14:26):
( or I missed it, so consider this just a double check ;-))
Lloyd McKenzie (Feb 16 2018 at 15:42):
I actually don't understand why we have the rule at all. If I've got a regex extension on string, why can't I use it on a uri? It'd be a bit weird to put it on a uuid, but there's nothing "wrong" about doing so. Or perhaps a minimum length on a code.
Grahame Grieve (Feb 16 2018 at 19:58):
does look there should be a task
Lloyd McKenzie (Feb 16 2018 at 21:22):
@Grahame Grieve Why do we need the exception at all?
Grahame Grieve (Feb 16 2018 at 21:25):
I expected a task about removing context altogether, not about abstract types in context
Lloyd McKenzie (Feb 16 2018 at 21:27):
I'm confused. Extensions need to have context - something that indicates where they're allowed to appear. I don't understand why extensions allowed on strings can't be used on specializations of string.
Grahame Grieve (Feb 16 2018 at 21:28):
sorry, I expected to see a task about removing contextType. Then the specialization issue would not come up
Lloyd McKenzie (Feb 16 2018 at 23:53):
So remove contextType - just list the datatype name or path or resource name or path - and remove the constraint on inheritance from strings?
Grahame Grieve (Feb 17 2018 at 00:47):
well, the constraint becomes irrelevant, and it become about the expression then. you can say what you want
Ewout Kramer (Feb 19 2018 at 15:12):
Last updated: Apr 12 2022 at 19:14 UTC
