Stream: conformance
Topic: Cause of no profile match
Grahame Grieve (Dec 09 2019 at 05:54):
So Lloyd and I have a question for people
Grahame Grieve (Dec 09 2019 at 05:55):
the validator is in process, and it comes across an element that has multiple profiles associated with it. It's valid if any one of the profiles is valid.
Grahame Grieve (Dec 09 2019 at 05:55):
so let's say none of the profiles are, because every one of them has an error.
Grahame Grieve (Dec 09 2019 at 05:56):
what we do now is report the primary (proximal?) error: this is not valid against any of the possible profiles
Grahame Grieve (Dec 09 2019 at 05:56):
then we report all the errors that we found trying to match against the profiles.
Grahame Grieve (Dec 09 2019 at 05:56):
but .... they're not errors in the same sense as other errors we report
Grahame Grieve (Dec 09 2019 at 05:56):
but they're not warnings either....
Grahame Grieve (Dec 09 2019 at 05:56):
any thoughts?
Thomas Tveit Rosenlund (Dec 09 2019 at 06:33):
The errors might just be categorized as information?
Grahame Grieve (Dec 09 2019 at 06:40):
we're concerned that calling them warnings or information will be confusing since they are kind of errors
Richard Townley-O'Neill (Dec 09 2019 at 06:53):
I think that failing to conform to a profile is only an error if there is a requirement to conform to the profile. All of the errors against the profiles are just information, the only error is the proximal one.
Jim Steel (Dec 09 2019 at 07:11):
But if you're failing to conform to a set of acceptable profiles, which non-conformance is the error?
Lloyd McKenzie (Dec 09 2019 at 13:49):
You can't tell which profile was the 'intended' profile the instance should have been valid against. The challenge is that the validation results against each of the candidate profiles might have error, warning and information messages - and any of those might be the clue that makes it obvious why the instance isn't validating successfully against one of the target profiles. If we change the severity of the profile validation reported back, it may be confusing and we'd be collapsing errors, warnings and possibly information messages into a single level. That would also mean it wouldn't be obvious which of the complaints were the actual 'error'.
Jason Walonoski (Dec 09 2019 at 22:40):
I think that the error should just be that the instance doesn't conform to any acceptable profiles and list the profiles. They can either then add a meta.profile (which I know is contentious here) or resubmit the $validate operation with a profile parameter. Don't try to guess what the user is doing.
Grahame Grieve (Dec 09 2019 at 22:41):
we're not trying to guess what the user is doing, just how to communicate what the validator is saying, and why
Lloyd McKenzie (Dec 09 2019 at 22:43):
Suppressing the detailed errors is certainly a viable approach. As a developer, it means more digging, but from an end user perspective, it's much less overwhelming.
Grahame Grieve (Dec 09 2019 at 22:45):
more digging that wouldn't be possible for profile (as oppose to targetProfile which Jason was talking about)
Grahame Grieve (Dec 09 2019 at 22:46):
but if we added the errors as an extension to OperationOutcome.issue, we could be explicit:
- error at path: None of the applicable profiles apply:
+(extension): profile XXXX: error
+(extension): profile XXXX: error
Lloyd McKenzie (Dec 09 2019 at 22:47):
Could be a honking lot of extensions. Perhaps render into a table in the detail?
Jason Walonoski (Dec 09 2019 at 22:48):
Well, you sort of are trying to guess what the user is doing since you're trying to decide what errors to report. My proposal is just to say "I don't know what you're trying to do, this is all wrong, it doesn't comply with any of my profiles. Try again and be more explicit."
Jason Walonoski (Dec 09 2019 at 22:52):
Regarding extensions, I guess I want to see what the JSON would look like before I got too excited. Sounds like a lot of extensions. Still think it is easier to just fail and say try again and tell me what this is supposed to be.
Grahame Grieve (Dec 09 2019 at 22:52):
but you can't be more explicit, and it may not be at all obvious why the validator thinks it doesn't comply
Grahame Grieve (Dec 09 2019 at 22:52):
tell me what this is supposed to be.
That's just not the point.
Jason Walonoski (Dec 09 2019 at 22:53):
but you can't be more explicit
Then I guess I don't know what we're talking about. The validate operation has a way to specify the profile. The resource has a way to specify the profile (meta.profile). The validator jar doesn't?
Grahame Grieve (Dec 09 2019 at 22:58):
because the acute presentation of this problem is for ElementDefinition.type.profile, not ElementDefinition.type.targetProfile
Jason Walonoski (Dec 09 2019 at 23:11):
Oh, I see.
Lloyd McKenzie (Dec 10 2019 at 00:03):
Grahame : any reason to prefer extensions over rendered detail? Do we think anyone would compute on these?
Grahame Grieve (Dec 10 2019 at 00:15):
yes:
- we render the operation outcome
- there are people post-processing the operation outcome
Brian Postlethwaite (Jan 01 2020 at 06:14):
Could be in the coded value. My fork if the net client puts in the system value as the profile url that is being processed, and the code as the invariant key (though this is a little more specific of a case, it thought could be relevant thought)
John Moehrke (Jan 01 2020 at 15:49):
is there a resolution to this problem? I am working on a draft of the IHE MHD profile using the IG publisher, and my examples are getting this warning. Yet my examples do match. in my IG examples I do explicitly include the profile each resource should be valid to, and have confirmed individually that they do. But in the transaction Bundle there is a miss of some kind to find the resource conformant to the overall profile. I don't know that I have the problem from this thread, but I am completely at a loss. Happy to have someone tell me where I messed up
http://build.fhir.org/ig/IHE/ITI.MHD/branches/master/index.html
Last updated: Apr 12 2022 at 19:14 UTC
