Stream: conformance
Topic: StructureDefinition.context
Ewout Kramer (Sep 28 2017 at 11:22):
Michel pointed out to me that Lloyd assumed StructureDefinition.context can be any kind of text. Indeed, this element is a string
- but I doubt very much tools would expect prose here. The intention - as far as I know - is for this element to contain a path (at least when the context type is Resource or Datatype). When would narrative be acceptable (if at all)?
Michel Rutten (Sep 28 2017 at 11:37):
Sorry for the confusion, here's Lloyd's earlier comments on extension context:
https://chat.fhir.org/#narrow/stream/implementers/subject/extensions
Lloyd McKenzie 04:35
"...If contextType is "resource", then the context must be a resource name or path. If contextType is "datatype" then the context must be a data type name or path. If contextType is extension, then the context must be the extension URL. I'm actually not sure how to refer to a sub-element within a complex extension..."
https://chat.fhir.org/#narrow/stream/implementers/subject/extensions.20Patient.20Name.20Parts
"2. Context must be a specific Resource path. It's computable."
So the exception is when contextType equals extension, then the context property apparently should specify a canonical url instead of an element path.
Ewout Kramer (Sep 28 2017 at 11:40):
Ok, so I agree on all that ;-) Maybe it wasn't Lloyd who thought it could by any text, then?
Michel Rutten (Sep 28 2017 at 11:42):
Found it, turns out the comment wasn't by Lloyd:
"Grahame Grieve 01:32
the conext can be any meaningful string, where meaning is specified by the contextType"
Ewout Kramer (Sep 28 2017 at 11:44):
Funny, those 01:32 timestamps. Makes ik look like "The Gospel according to...."
Ewout Kramer (Sep 28 2017 at 11:45):
That's ok, as long as "meaningful" here means "a FhirPath(?) path" for type={resource,datatype}, "uri" for type={extension} etc....
Chris Grenz (Sep 28 2017 at 12:52):
@Ewout Kramer does FHIRPath have any kind of hi/low complexity categories? As in, a context must be a simple FHIRPath expression? Or is the whole syntax always available?
Chris Grenz (Sep 28 2017 at 12:54):
Also, note that URIs may include locators:
http://example.com/StructureDefinition/my-extension#Extension.extension:firstPart.valueString
Is this legal for context on extensions?
Ewout Kramer (Sep 28 2017 at 12:55):
@Ewout Kramer does FHIRPath have any kind of hi/low complexity categories? As in, a context must be a simple FHIRPath expression? Or is the whole syntax always available?
The notion of "flavors" of FHIRPath has been popping up a few times....e.g. in GF#13711...
Ewout Kramer (Sep 28 2017 at 12:56):
SearchParameters, discriminator paths, extension context....
Chris Grenz (Sep 28 2017 at 12:56):
Chris Grenz (Sep 28 2017 at 12:57):
Thinking about writing a native node.js snapshot generator/validator and FHIRPath makes my life very difficult
Ewout Kramer (Sep 28 2017 at 12:59):
Just a snapshot->FHIRPath translator and then an efficient FHIRPath engine would do ;-) I had some philosophical discussions with Bryn about additions to FHIRPath to make the structural constraints in an SD translateable to FHIRPath. But your error reporting to the user would probably be absymal. Anyway, don't want to punish your brains any more than necessary ;-)
Ewout Kramer (Sep 28 2017 at 13:01):
Also, note that URIs may include locators:
http://example.com/StructureDefinition/my-extension#Extension.extension:firstPart.valueString
Is this legal for context on extensions?
Have not given that a thought yet....but in the links Michel included above, I see Lloyd wonder about how to specify a context within an extension. This might be it..
Chris Grenz (Sep 28 2017 at 13:06):
There are tiers of functionality (I think) in what profiles do and how they can be applied. Things like:
- Converting a profile into search criteria to apply the profile to the whole server
- Using profiles (with slices) to create a better specified schema (Patient with an "officialName" element)
- Stream parsing of resources to avoid having to keep large resources in-memory
Because there aren't (yet) public examples of any of these kinds of things, it's tempting to make really complex FHIRPath constraints, and those will keep these profiles from being used in highly optimizing parsers
Lloyd McKenzie (Sep 28 2017 at 14:50):
We should certainly document how to point to sub-elements within an extension. Chris, do you want to submit a tracker on that?
Michel Rutten (Sep 28 2017 at 14:54):
I seem to remember that I wrote some logic in Forge or .NET API before concerning url's that walk into a complex extension using anchor notation. I think this aligns with the example above, but I'll check.
Grahame Grieve (Oct 03 2017 at 03:04):
I certainly intended for the context string to reference an element but it's id not by it's path - e.g. not FHIRPath. Not here.
Grahame Grieve (Oct 03 2017 at 03:06):
context is either an element but it's id, or it's canonical url.
Grahame Grieve (Oct 03 2017 at 03:06):
it could be cleaner to make it always a full URL that identifies an element authoritatively.
Michel Rutten (Oct 03 2017 at 10:38):
So if I understand correctly, it is valid for the context property to specify an element id, e.g. "Patient.identifier:ssn"?
Grahame Grieve (Oct 03 2017 at 11:44):
that would be problematic - which :ssn? that's why I was thinking about making it a full url
Michel Rutten (Oct 03 2017 at 12:03):
So if I understand correctly, this would allow an extension definition to state: I am designed to be used in profiles derived from a specific base profile and on a specific slice? Advanced, but I see how this might be useful.
Grahame Grieve (Oct 03 2017 at 12:08):
yes could do that. I would encourage to be a little more general, but people do want to be extremely specific
Michel Rutten (Oct 03 2017 at 12:10):
Agreed. So maybe we should not proactively change this until there is sufficient demand from the community?
Grahame Grieve (Oct 03 2017 at 12:11):
going normative in R4.
Michel Rutten (Oct 03 2017 at 12:15):
I see, then I guess we have to define the proper format now.
Chris Grenz (Oct 03 2017 at 19:44):
Format is set when we locked the format of elementdefinition.id.
http://example.com/my-us-patient#Patient.identifier:ssn
Last updated: Apr 12 2022 at 19:14 UTC