Stream: fhirpath
Topic: name.given1
Paul Lynch (Oct 18 2018 at 22:42):
There is test in tests-fhir-r4.xml which says that "name.given1", when run on patent-example.xml, should be an invalid expression. Why would that not return the empty set (indicating that there is no given1 field on that name structure)?
Brian Postlethwaite (Oct 19 2018 at 02:19):
Is that in the tests that understand type information?
Grahame Grieve (Oct 19 2018 at 05:12):
that test is specifically testing that the engine knows that given1 is not a valid property name for the class
Paul Lynch (Oct 23 2018 at 16:11):
Would that be test of the FHIRPath specification (http://hl7.org/fhirpath/2018Sep/) or of the FHIR extensions (http://hl7.org/fhir/2018Sep/fhirpath.html)? (I am having trouble seeing in either place that raising an error is the right behavior, but I am quite possibly just missing it.)
Brian Postlethwaite (Oct 23 2018 at 21:02):
I use that knowledge when validating constraints in a structure definition to be sure that it is valid on the instance it is expected to run on (and similarly on questionnaire definition validation, that when defining links in the fhirpath that they actually exist in the questionnaire. Kinda fun)
Bryn Rhodes (Oct 24 2018 at 02:13):
@Paul Lynch , I would have expected to find it here, but I think you're right, the spec does not explicitly state that an invalid property name is an error condition. It should be in the base FHIRPath spec, not in the FHIR extensions, and given that the behavior is verified with a test, I think this is a case of the implementations being ahead of the spec.
Paul Lynch (Oct 24 2018 at 14:27):
That's fine. It would be very helpful for it to be in the spec, because I was not expecting that behavior.
Brian Postlethwaite (Oct 26 2018 at 06:59):
I think it's a behaviour of the models that its applied against, not the core fhirpath spec.
Paul Lynch (Oct 26 2018 at 16:35):
@Brian Postlethwaite Are you suggesting that some models would raise an error if an invalid property name was requested, but that other models would not?
Bryn Rhodes (Oct 26 2018 at 18:24):
Yeah, that's not my understanding. Brian, is that a feature of your engine?
Brian Postlethwaite (Oct 26 2018 at 21:31):
Yup. I add more validation rules for the various uses i have.
I dont suspect others are checking linkids for questionnaires.
Have been thinking about checking codes too, as with a known binding, can check that the value in the expression exists in the set.
Not expecting that to be documented in the spec though.
Grahame Grieve (Oct 27 2018 at 07:59):
I think that maybe we should categorise the tests so you can ignore tests that depend on validation against the underlying model, if you're not intersted in that
Paul Lynch (Oct 27 2018 at 19:21):
@Grahame Grieve That would help, but also along those lines (and as I thought I suggested somewhere, but I can't find it) I think it would be good for FHIRPath to have its own file of tests, separate from the tests that are for the FHIR-specific features.
Grahame Grieve (Oct 27 2018 at 19:24):
well, you're welcome to define them...
Paul Lynch (Oct 27 2018 at 19:26):
I didn't necessarily mean new tests, but that the core FHIRPath tests in tests-fhir-r4.xml could be separated into its own file.
Grahame Grieve (Oct 27 2018 at 19:27):
there's a lot that wouldn't be tested that way
Paul Lynch (Oct 27 2018 at 19:29):
I'm not sure why. FHIRPath engines would be tested with (at least) the core FHIRPath tests, and R4 FHIRPath engines would be tested with those plus whatever was left in tests-fhir-r4.xml
Grahame Grieve (Oct 27 2018 at 19:29):
because anything to do with objects (as opposed to primitives) needs some objects to test with.
Paul Lynch (Oct 27 2018 at 19:31):
Objects are not a problem. The fhirpath.js engine has no knowledge of FHIR types, but is still using the FHIR resources as the data against which test expressions (in tests-fhir-r4.xml) are run.
Paul Lynch (Oct 27 2018 at 19:31):
It just doesn't know (or care) that those resources are FHIR resources.
Grahame Grieve (Oct 27 2018 at 19:32):
I don't understand what you're trying to do then
Grahame Grieve (Oct 27 2018 at 19:33):
what's the point of separating out the dependencies that you need anyway?
Paul Lynch (Oct 27 2018 at 19:33):
To separate the tests like name.given1 (which require validation against a known FHIR model) from other tests that don't require knowledge of FHIR types.
Grahame Grieve (Oct 27 2018 at 19:33):
oh well that's what I suggested, so I thought you must mean something else
Paul Lynch (Oct 27 2018 at 19:36):
Okay good. I thought you were talking about adding a flag to certain tests that would allow them to be skipped over. That would still mean that a FHIRPath engine (which might I suppose not be used for FHIR itself) would still need to be pulling in tests-fhir-r4.xml (or r5.xml....) which if FHIRPath is its own thing, does not seem ideal.
Grahame Grieve (Oct 27 2018 at 19:38):
so my confusion remain. I was talking about adding a flag. But your separated tests will still need to pull in the source that supports tests-fhir-r4.xml... so I don't know what the point is
Paul Lynch (Oct 27 2018 at 19:40):
The separated test file for core FHIRPath would start out with copies of the resources the tests referenced, and would be available as a download from the FHIRPath page, not a FHIR page. The resources would not need to be (or remain) valid FHIR resources, and could be changed as necessary to support new FHIRPath tests (possibly invalidating those resources, but it wouldn't matter).
Grahame Grieve (Oct 27 2018 at 19:43):
well, I think it would matter since now the tests could not be used for engines that used FHIR
Paul Lynch (Oct 27 2018 at 19:48):
Perhaps it would depend on how those engines are implemented. I was thinking that if eventually fhirpath.js has knowledge of FHIR types, that knowledge would be passed into it as an optional argument, so that it could be checking against R3, R4, or something non-FHIR. If nothing was provided, it would not do anything with types.
I can see how this separation might be disruptive for existing FHIRPath engines, but I think the case for it will become stronger over time now that FHIRPath is its own spec.
Paul Lynch (Oct 27 2018 at 19:50):
In any case, a flag as you suggest would be an improvement.
Brian Postlethwaite (Oct 27 2018 at 22:10):
The .net engine is fully separated, and does have both styles of tests in it. As well as running the core tests.
Brian Postlethwaite (Oct 27 2018 at 22:11):
Having the flag sounds like it would achieve your result.
Like grahame said, you need models to test with.
Last updated: Apr 12 2022 at 19:14 UTC
