Stream: conformance
Topic: type slicing ordered
Patrick Werner (Apr 27 2020 at 10:49):
The Java Validator throws an error if you have a ordered type slicing (slicing like this doesn't make a lot of sense in the first place). The .net validator (Simplifier) accepts ordered type slicing.
I think it could make sense to add a constraint on discriminator to raise at least a warning if you want to do ordered type slicing.
Grahame Grieve (Apr 27 2020 at 11:13):
it's actually the snapshot generator, though that doesn't really matter
Grahame Grieve (Apr 27 2020 at 11:14):
I declined to support because I have no idea what it means to claim that they are ordered
Lloyd McKenzie (Apr 27 2020 at 14:53):
There could only be meaning if polymorphic types could be repeating - and they can't. So I think asserting ordered type slicing as an error is reasonable.
Lloyd McKenzie (Apr 27 2020 at 14:55):
Actually, let me re-think that. If the profile reaches through a repeating path, it could make sense. E.g. entry.resource. In that case, you'd be asserting that some resources needed to appear before other resources. (Though whether that's a legal thing to do is unclear. It's certainly a questionable practice... In fact, using ordered slicing on any element where order doesn't have defined meaning is pretty questionable.)
Grahame Grieve (Apr 27 2020 at 20:31):
doesn't apply to entry resource, since that's not a choice of types
Patrick Werner (Apr 28 2020 at 10:44):
do we need an invariant for this? @Ward Weistra
Ward Weistra (Apr 28 2020 at 14:55):
@Patrick Werner Sounds fair to me, though not an expert. Can you suggest it on https://github.com/FirelyTeam/fhir-net-api/ so our API team can consider?
Patrick Werner (Apr 28 2020 at 14:56):
Sure. To be safe in the future i think we should add this as an error invariant.
Patrick Werner (Apr 29 2020 at 07:00):
Ok. Gave it some more thought. Some (German) Implementers love the ordered slicing on type. They use it to express stuff like: "First Practitioner is sending the patient, second Practitioner is receiving the patient". They use it to give semantical meaning on Resources they can't distinguish by a code or other criteria.
Patrick Werner (Apr 29 2020 at 07:01):
I can follow that thought, it looks good in Simplifier to have a defined order if you have no other criteria to slice on.
Patrick Werner (Apr 29 2020 at 07:02):
But validating such ordered type slicings is impossible. That's why @Grahame Grieve is not supporting it. Right?
Patrick Werner (Apr 29 2020 at 07:04):
Open Question: Should ordered slicing on type be prohibited by an error invariant, so StrucDefs using it won't validate? Or should this be 'legal' and the Validator throws a warning when validating an instance saying: i can't validate this ? Or even just ignores it.
Patrick Werner (Apr 29 2020 at 07:05):
As Simplifier doesn't raise an error on this i'm interested on @Ewout Kramer s opinion on this.
Patrick Werner (Apr 29 2020 at 07:18):
I think being able to do something in the .Net stack and getting Exceptions for the same in the Java stack is not good for FHIR and interoperability.
Grahame Grieve (Apr 29 2020 at 07:53):
They use it to express stuff like: "First Practitioner is sending the patient, second Practitioner is receiving the patient"
This is not slicing on type
Patrick Werner (Apr 29 2020 at 08:23):
I'm not sure what you are implying. Here is an example: https://simplifier.net/patrickssandbox/myobservation
closed type based ordered slicing on derivedFrom()
Mareike Przysucha (Apr 29 2020 at 08:25):
But those are both normal Observations. If you get an observation, how do you distinguish whether it's obs1 or obs2?
Patrick Werner (Apr 29 2020 at 08:40):
first one is obs1, second obs2. Sliced by type, defined order. Not saying that i like this, or this is good practice. Just pointing to the fact that some people are using it that way.
Patrick Werner (Apr 29 2020 at 08:41):
Yes proper validation isn't possible, as you never know if someone changed the order. So a computer can't validate this, but extensible is also not validateable by a computer.
Mareike Przysucha (Apr 29 2020 at 08:41):
sorry, I did not see the cardinalities.
Patrick Werner (Apr 29 2020 at 08:41):
My goal is consistency between .net, (Simplifier/Forge) and the Java Stack
Grahame Grieve (Apr 29 2020 at 09:44):
so derivedFrom is a Reference with cardinality 0..* This is not type slicing
Patrick Werner (Apr 29 2020 at 10:02):
:scream: i'm confused now.
Grahame Grieve (Apr 29 2020 at 10:08):
type slicing is when you have something like Observation.value[x] and you have a slice for string and a slice for CodeableConcept
Grahame Grieve (Apr 29 2020 at 10:09):
cardinality is 0..1, and so there's no repeats and you can't talk about order.
Grahame Grieve (Apr 29 2020 at 10:09):
Observation.derivedFrom, of course you need to be able to talk about order
Patrick Werner (Apr 29 2020 at 10:10):
ohhh. Just learned something. Thanks.
Patrick Werner (Apr 29 2020 at 12:34):
i'm totally confused now. Sorry. Looking at: https://www.hl7.org/fhir/profiling.html#discriminator
I see:
Used to match slices based on the type of the item. While it can be used with polymorphic elements such as Observation.value[x], mostly it is used with Resource types on references, to apply different profiles based on the different resource type. Typical example: slice on the type of List.item.resolve() for the types Patient, RelatedPerson.
Patrick Werner (Apr 29 2020 at 12:37):
Which says i can use this for reference types. (Doesn't say anything about 'can only be used on references with max card. =1 )
Patrick Werner (Apr 29 2020 at 12:37):
I also couldn't find another possibility to slice references based on the target reference type (not profile, just core type)
Lloyd McKenzie (Apr 29 2020 at 13:56):
The Germans shouldn't assign meaning to the order when the core spec doesn't define order to have meaning - doing so is non-conformant. If there's a different semantic between repetitions, then expose it in the instance and continue to allow the data to be sent in arbitrary order. Imposing order (and meaning on order) where the spec says there isn't any is contrary to interoperability and sometimes dangerous
Patrick Werner (Apr 29 2020 at 14:00):
I agree. Thats why i think there should be an invariant or a warning from the Validator itself on this to give explicit guidance. The non-conformancy isn't stated explicitly on the slicing page.
On the other hand, Grahame said:
Observation.derivedFrom, of course you need to be able to talk about order
Which i interpret as its ok to talk about order in a list.
What's your opinion on slicing on a target type?
Grahame Grieve (Apr 29 2020 at 19:33):
yes you need to slice in target type. I can see that the language here is confusing - by "type based slicing" I meant, slicing an element that has a choice of types, not using a "type" discriminator
Patrick Werner (Apr 30 2020 at 06:30):
:relieved: ok. Thats a relief.
Last updated: Apr 12 2022 at 19:14 UTC
