Stream: implementers
Topic: OperationOutcome location vs. expression
Lloyd McKenzie (Jul 17 2018 at 20:56):
In OperationOutcome, we have two elements that serve the same purpose. OperationOutcome.location was the original and uses a limited XPath + some hokey stuff for http parameters. OperationOutcome.expression is newer and, to the best of my knowledge, doesn't support http parameter identification. When we first introduced 'expression', the intention was to eventually fade away 'location' so that we'd only have a single non-syntax-specific mechanism for identifying the location of the issue described by the OperationOutcome. However, we haven't yanked it yet and we're approaching the point where we won't be able to yank it. Also, because the functionality of both elements isn't identical, yanking location is problematic.
We need to decide two things:
1. What should we do with OperationOutcome.location?
a) Remove it prior to R4 publication
b) Mark it as deprecated and as STU allowing for removal in R5 or some other future release
c) Leave it as is (and set expectations as to when it should be populated in addition to/instead of expression
2. For those who are using the 'expression' element, how do we want to handle identifying http search parameters? Options include doing the same thing we did for location or adding a separate element (allowing the expression to remain 'pure' FHIRPath)
Opinions welcome - but we need to land this in the next 4 weeks...
Grahame Grieve (Jul 17 2018 at 21:30):
I think we should move to a single location, a simple fhirpath, with a %http context to address the headers
Last updated: Apr 12 2022 at 19:14 UTC
