Stream: conformance
Topic: Discriminator syntax
Lloyd McKenzie (Jan 06 2017 at 21:29):
So, I'm poking around the validator and the fact that it doesn't (yet) support everything that the documentation says is theoretically possible. And I'm actually finding that the documentation is somewhat deficient. First, I think the ElementDefinition.slicing.discriminator element needs to point to the appropriate section on the profiling page where the syntax is defined. Second, we've sort of adopted a bit of FHIRPath but haven't defined exactly what's going on - or even said we're uing FHIRPath even though it manifests in the examples (e.g. item.extension("http://acme.org/extensions/test").code - which should actually be item.extension("http://acme.org/extensions/test").value I think)
As I understand it, when we slice we define a path - which is a "simple" FHIRPath. I think that means that we can navigate nodes and we can use the "extension" function to navigate by URL. Are there any other parts of FHIRPath we allow? If so what?
Appended to that path, we might then have .@profile or .@type which tells how the slicing is resolved. But in practice we have 5 different mechanisms for resolving slicing:
If @profile is declared, then within each slice, there must be an element at the specified path and that element must declare a profile or a target profile (and all slices must be consistent about which they declare and the list of profiles referenced must be distinct and the profiles must be mutually exclusive, though the latter won't be tested)
If @type is declared, then within each slice there must be an element at that path and the data type for each matching slice element must be distinct
Otherwise one of three situations must hold:
- every slice defines an element at the specified path and those elements all have a fixed value (and those values are distinct)
- every slice defines an element at the specified path and those elements all have a binding to a value set (and those value sets are distinct. They must also be non-overlapping - validator might bother to check this, but probably not)
- there must be exactly two slices both each defining the element at the specified path. Of those one must have a minOccurs >=1 and the other must have a maxOccurs of 0. (The slicing is based on the existence or non-existence of the specified element.)
I'm wondering whether it would be cleaner to say that the path must always end with one of the following: @profile, @type, @fixed, @valueset or @exists. That would make it very clear what's going on
Grahame Grieve (Jan 09 2017 at 11:03):
I think it would be good to be explicit. I'm not sure that the proposed syntax quite makes sense
Lloyd McKenzie (Jan 09 2017 at 22:54):
Well, what would make the most sense is if we made discriminator a complex object with two properties - path and type where type is type|profile|fixed|valueset|exists
Lloyd McKenzie (Jan 16 2017 at 16:06):
Last updated: Apr 12 2022 at 19:14 UTC
